From murad.ansarin@akdsecurities.net Wed Apr 1 04:13:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46B23A6B78 for ; Wed, 1 Apr 2009 04:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 CuWj2oMSbjFZ for ; Wed, 1 Apr 2009 04:13:29 -0700 (PDT) Received: from HSI-KBW-095-208-048-216.hsi5.kabel-badenwuerttemberg.de (HSI-KBW-095-208-048-216.hsi5.kabel-badenwuerttemberg.de [95.208.48.216]) by core3.amsl.com (Postfix) with SMTP id 217893A68A1 for ; Wed, 1 Apr 2009 04:13:27 -0700 (PDT) To: Subject: Bank account blocked From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090401111328.217893A68A1@core3.amsl.com> Date: Wed, 1 Apr 2009 04:13:27 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Wed Apr 1 07:25:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B10028C141; Wed, 1 Apr 2009 07:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.452 X-Spam-Level: **** X-Spam-Status: No, score=4.452 tagged_above=-999 required=5 tests=[AWL=-2.098, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MANGLED_LIST=2.3, 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 EM+9npPI25Lu; Wed, 1 Apr 2009 07:25:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E102128C0FC; Wed, 1 Apr 2009 07:25:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lp1CZ-000O4T-14 for namedroppers-data0@psg.com; Wed, 01 Apr 2009 14:13:59 +0000 Received: from [213.178.172.147] (helo=WOTAN.TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lp1CR-000O37-2F for namedroppers@ops.ietf.org; Wed, 01 Apr 2009 14:13:55 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA104565105; Wed, 1 Apr 2009 16:11:46 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA22440; Wed, 1 Apr 2009 16:11:40 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200904011411.QAA22440@TR-Sys.de> Subject: [dnsext] draft-ietf-dnsext-axfr-clarify-11 To: ed.lewis@neustar.biz, namedroppers@ops.ietf.org Date: Wed, 1 Apr 2009 16:11:39 +0200 (MESZ) 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: Edward, thanks for your work on updating the AXFR draft. I have followed up to the new version, draft-ietf-dnsext-axfr-clarify-11, and did not find any more substantial flaws. Therefore, I strongly suggest that the chairs now call out this draft for WGLC. In this case, please regard this message as a WGLC comment. Below, I have assembled a list of editorials left over from previous draft versions or newly introduced with new text into the -11 version. I suggest that these details be addressed together with any potential WGLC comments in a final draft version before handing the document over to the IESG. (1) Abstract -- spurious comma The definition of AXFR, has proven insufficient ... --- ^ The definition of AXFR has proven insufficient ... (2) Section 2, last para -- language 'OBE' The draft says: vvvvvv | Field names used in this document will correspond to the names as they appear in the IANA registry for DNS Header Flags [DNSFLGS]. That was literally perfect until a new paragraph has been inserted before, giving a preview of the treatment of the TC bit. This way, the "will" has become moot; I suggest to simply drop this word: v | Field names used in this document correspond to the names as they appear in the IANA registry for DNS Header Flags [DNSFLGS]. (3) Section 2.1, 1st para -- copyedit flaw The first paragraph is the old text that was intended to be replaced by the new text that now appears as the second paragraph in the section, but inadvertantly has been kept. So please delete the first paragraph in 2.1. (4) Section 2.2, 3rd para -- clarification I still fear that the current text might be considered misleading. The draft says: vvvvvvv | 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 terminate the AXFR session; it MUST copy the Query Section from the AXFR query into its Query Section, but the inclusion of the terminating SOA resource record is not necessary. An AXFR client might receive a number of AXFR response messages free of an error condition before the message indicating an error is received. The last paragraph also quoted above clarifies that an error response can consist of multiple DNS messages, formally contradicting the "single" in the first line of the third paragraph. Thus, the phrase, "An AXFR response ... indicating an error MUST consist of a single DNS message ..." is misleading and should be reworded for clarity. Actually, the error response may consist of multiple AXFR response messages, with exactly one (the last one) carrying an error code. This should be unambiguously clear from the first mention. Here is a new proposal using simplified language for the first sentence in the third paragraph: | An AXFR response indicates an error via a single DNS message with the return code set to the appropriate value for the condition encountered | - sent once the error condition is detected. Such a message MUST terminate the AXFR session; it MUST copy the Query Section from the AXFR query into its Query Section, but the inclusion of the terminating SOA resource record is not necessary. (5) Section 3.1, last paragraph -- improper plural Please correct: vv | Zones for which it is impractical to list the entire zones for a serial number ... --- v | Zones for which it is impractical to list the entire zone for a serial number ... (6) Section 3.2, bullets below "Informally:" There are two typos in these bullets. [ Sorry, I'm eventually guilty myself for these. :-( ] - 3rd bullet: s/bth/both/ - 4th bullet: s/siede/side/ (7) Section 3.4, last para -- 'rational quotation' (#1) Please adjust the quotation style to what has been adopted in the IETF. There are a few instances that still need to be fixed. The first one is at the end of the last paragraph of Section 3.4: Compression." --- vv Compression". (8) Section 3.5, 1st para -- 'rational quotation' (#2) As in (7) above, please correct at the end of the first paragraph: said to be "occluded." --- vv said to be "occluded". (9) Section 4, 3rd para -- punctuation The comma in that paragraph separates two full sentences. Therefore it should better be replaced by a semicolon (or use a full stop instead, if you prefer!): The assumption that a TCP connection is dedicated to the single AXFR | session is incorrect, this has led to implementation choices that prevent either multiple concurrent zone transfers or the use of the open connection for other queries. --- The assumption that a TCP connection is dedicated to the single AXFR | session is incorrect; this has led to implementation choices that prevent either multiple concurrent zone transfers or the use of the open connection for other queries. (10) Section 4.1, last para, last sentence -- improved language The latest changes lead to poor grammar. [ Perhaps I'm guilty for that oversight as well. :-( ] I suggest to improve the sentence and punctuation as follows: [...] In the reverse situation, older AXFR client and newer AXFR server ought to induce the server to operate within the specification for an older server. --- | [...] The reverse situation, older AXFR client and newer AXFR v ^^ | server, ought to induce the server to operate within the specification for an older server. Or use: [...] In the reverse situation, older AXFR client and newer AXFR | server, the server ought to operate within the specification for an ^^ ^^^^^^^ older server. (11) Section 4.1.1, 1st para -- 'rational quotation' (#3) Similar as above, please correct: is "apparent need." --- vv is "apparent need". (12) Section 4.1.1, 3rd paragraph -- improved wording The text near the end of the paragraph refers to previous phrases by three keywords, where the keyword "failure" does not appear in the text currently. But there is un unpleasant word repetition of "disruption", and so I suggest to s/disruption/failure/ : OLD: When a TCP connection is closed remotely (relative to the client), whether by the AXFR server or due to a network event, the AXFR client MUST cancel all outstanding sessions and non-AXFR transactions. Recovery from this situation is not straightforward. If the disruption was a spurious event, attempting to restart the connection would be proper. If the disruption was caused by a medium or long term | disruption, the AXFR client would be wise to not spend too many ^^^^^^^^^^ resources trying to rebuild the connection. Finally, if the connection was dropped because of a policy at the AXFR server (as can be the case with older AXFR servers), the AXFR client would be wise to not retry the connection. Unfortunately, knowing which of the three cases above ! (momentary disruption, failure, policy) applies is not possible with !!!!!!! certainty, and can only be assessed by heuristics. NEW: When a TCP connection is closed remotely (relative to the client), whether by the AXFR server or due to a network event, the AXFR client MUST cancel all outstanding sessions and non-AXFR transactions. Recovery from this situation is not straightforward. If the disruption was a spurious event, attempting to restart the connection would be proper. If the disruption was caused by a medium or long term | failure, the AXFR client would be wise to not spend too many ^^^^^^^ resources trying to rebuild the connection. Finally, if the connection was dropped because of a policy at the AXFR server (as can be the case with older AXFR servers), the AXFR client would be wise to not retry the connection. Unfortunately, knowing which of the three cases above (momentary disruption, failure, policy) applies is not possible with certainty, and can only be assessed by heuristics. (13) Section 5, last para -- 'rational quotation' (#4) Again, please adjust: [...] to be "open to all." [...] --- vv [...] to be "open to all". [...] (14) Section 7.1, last para Apparently, the last two words and the trailing period have been lost. Please restore: An implementation of an AXFR server MAY permit configuring, on a per AXFR client basis, a need to revert to single resource record per message; in that case, the default SHOULD be to use multiple records --- An implementation of an AXFR server MAY permit configuring, on a per AXFR client basis, a need to revert to single resource record per message; in that case, the default SHOULD be to use multiple records | per message. (15) Section 11, 1st para -- punctuation I suggest to replace the trailing period by a colon (':') to better introduce the subsequent literal quotation. Earlier editions of this document have been edited by Andreas | Gustafsson. In his latest version, this acknowledgement appeared. --- Earlier editions of this document have been edited by Andreas | Gustafsson. In his latest version, this acknowledgement appeared: ^ (16) Section 12 a) According to the exegesis by the IESG, RFC 2119 (BCP 14) is to be understood as a normative reference. So please promote the entry '[BCP14]' in Section 12.2 to Normative, by moving it into Section 12.1. Further, it might be wise (and more consistent in style) to also use '[RFC2119]' in place of '[BCP14]'. b) As a service to the reader, I suggest to restore the collation order (i.e. RFCs listed in ascending RFC number order) in Section 12.1. The order has been distorted a bit by updates due to obsolescences and late additions. The following entries need to be moved down to the proper plase: [RFC5395] , [RFC4509] , and [RFC5155] . 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 p8ntballmaniac86@aim.com Wed Apr 1 09:46:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDDC3A68B5 for ; Wed, 1 Apr 2009 09:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.647 X-Spam-Level: X-Spam-Status: No, score=-28.647 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, 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 jkOqPB++SvA9 for ; Wed, 1 Apr 2009 09:46:58 -0700 (PDT) Received: from catv3EC94648.pool.t-online.hu (catv3EC94648.pool.t-online.hu [62.201.70.72]) by core3.amsl.com (Postfix) with SMTP id 0A6763A6949 for ; Wed, 1 Apr 2009 09:46:56 -0700 (PDT) To: Subject: Update - Credit card blocked From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090401164657.0A6763A6949@core3.amsl.com> Date: Wed, 1 Apr 2009 09:46:56 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Wed Apr 1 11:22:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF7E3A6DA3; Wed, 1 Apr 2009 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 fCdSeiglaXmL; Wed, 1 Apr 2009 11:22:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E0273A6BF6; Wed, 1 Apr 2009 11:22:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lp4zF-000HOx-8J for namedroppers-data0@psg.com; Wed, 01 Apr 2009 18:16:29 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lp4z9-000HOO-Dd for namedroppers@ops.ietf.org; Wed, 01 Apr 2009 18:16:26 +0000 Received: from [10.31.200.209] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n31IGEol006110; Wed, 1 Apr 2009 14:16:16 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200904011411.QAA22440@TR-Sys.de> References: <200904011411.QAA22440@TR-Sys.de> Date: Wed, 1 Apr 2009 14:16:11 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] Re: draft-ietf-dnsext-axfr-clarify-11 Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I processed these suggestions - and am waiting on hearing from the WG's chairs. At 16:11 +0200 4/1/09, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >Edward, >Therefore, I strongly suggest that the chairs now call out >this draft for WGLC. >(1) (2) (3) ack cubed >(4) Section 2.2, 3rd para -- clarification >| An AXFR response indicates an error via a single DNS message with the > return code set to the appropriate value for the condition encountered >| - sent once the error condition is detected. Such I omitted the dash from the suggestion. >(5) (6) Ack squared. >(7) (8) ... 'rational quotation' Oh, alright but now the doc is inconsistent (other quotes are irrational) - squared. >(9) Went with the full-stop; I'm not a fan of semi-colons. >(10) > [...] In the reverse situation, older AXFR client and newer AXFR >| server, the server ought to operate within the specification for an > older server. Used the latter option - fewer words. >(11) 7/8's squared response is now cubed. >(12) I went with something a little different "...If the disruption was caused by a failure that proved to be persistent, the AXFR client would be wise to not spend too many resources trying to rebuild the connection. ... ... Unfortunately, knowing which of the three cases above (momentary disruption, persistent failure, policy) applies is not possible with certainty, and can only be assessed by heuristics." In the same spirit, but I used "proved to be" to indicate that the failure of the connection came at then onset of an event (like a router flaming out) and then later refer to "persistent failure." Or "persistent failure".) >(13) ... 'rational quotation' (#4) Once squared, then cubed, now (umm) err, fourthed. >(14) (15) ack ack >(16) >a) >According to the exegesis by the IESG, RFC 2119 (BCP 14) is to >be understood as a normative reference. So please promote the >entry '[BCP14]' in Section 12.2 to Normative, by moving it into >Section 12.1. >Further, it might be wise (and more consistent in style) >to also use '[RFC2119]' in place of '[BCP14]'. I kind of want to emphasize that it is also a BCP. This kind of elevates the document above mere RFCdom. In general, I've been trying to break the habit of using the RFC numbers as jargon to help remind me what it is (in general) we are doing. Still, moved it to the normatives. >b) ack - wonder why that got messed up. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From kvetaa@amcat.com Thu Apr 2 07:06:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9973A6A67 for ; Thu, 2 Apr 2009 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.971 X-Spam-Level: X-Spam-Status: No, score=-22.971 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 cyS2h9BIq7xC for ; Thu, 2 Apr 2009 07:06:41 -0700 (PDT) Received: from aisystem.cl (unknown [96.41.216.231]) by core3.amsl.com (Postfix) with SMTP id 1774B3A6AA6 for ; Thu, 2 Apr 2009 07:06:39 -0700 (PDT) To: Subject: Credit card PIN is invalid From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090402140640.1774B3A6AA6@core3.amsl.com> Date: Thu, 2 Apr 2009 07:06:39 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From boyd@enniebudy.com Thu Apr 2 12:35:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E363A6A6E; Thu, 2 Apr 2009 12:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.649 X-Spam-Level: X-Spam-Status: No, score=-11.649 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_SPEC_ROLEX=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 1IuBuHlXDmwj; Thu, 2 Apr 2009 12:35:10 -0700 (PDT) Received: from 201-42-195-76.dsl.telesp.net.br (201-42-195-76.dsl.telesp.net.br [201.42.195.76]) by core3.amsl.com (Postfix) with SMTP id 40B4128C26A; Thu, 2 Apr 2009 12:34:56 -0700 (PDT) X-Originating-IP: 131.240.64.27 by smtp.201.42.195.76; Thu, 02 Apr 2009 13:31:56 -0700 Message-ID: <7764wj9747INPGdhcwg-bounces@ietf.org> Date: Thu, 02 Apr 2009 15:35:56 -0500 From: "Keisha Blair" To: "Keisha Blair" Subject: Why get an original watch? Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A fine designer watch says means refinement and money. A fine, non-expensive designer watch also means intelligence! http://vuvajowom.cn/ Diam0nd Reps has it all: Rolex, Cartier, Tag Heuer, Breitling, and many more, for a fraction of the price of an original watch. And don't forget: when you order two watches, you get an extra 15 percent discount over our already low prices! http://vuvajowom.cn/ With so many watches that look and work like the real thing, I guarantee you'll have a delicious time finding yours at our store! From kusatsuduki@ag.main.jp Thu Apr 2 15:16:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D1C3A68DD for ; Thu, 2 Apr 2009 15:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.927 X-Spam-Level: * X-Spam-Status: No, score=1.927 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 h445YOM90+1S for ; Thu, 2 Apr 2009 15:16:39 -0700 (PDT) Received: from 212.199.141.14.static.012.net.il (212.199.141.14.static.012.net.il [212.199.141.14]) by core3.amsl.com (Postfix) with SMTP id 40FB03A67A1 for ; Thu, 2 Apr 2009 15:16:36 -0700 (PDT) To: Subject: Mortgage loan information From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090402221637.40FB03A67A1@core3.amsl.com> Date: Thu, 2 Apr 2009 15:16:36 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From jgonzalez@airredes.com Thu Apr 2 20:05:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5EC3A6B00; Thu, 2 Apr 2009 20:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.273 X-Spam-Level: X-Spam-Status: No, score=-20.273 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_EQ_PPPOE=0.35, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HELO_EQ_PPPOE=0.555, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 KQZy-R+14-Nu; Thu, 2 Apr 2009 20:05:35 -0700 (PDT) Received: from PPPoE-78-29-84-255.san.ru (PPPoE-78-29-84-255.san.ru [78.29.84.255]) by core3.amsl.com (Postfix) with SMTP id AAC313A6930; Thu, 2 Apr 2009 20:05:14 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "Franklin Abbott" To: "Chadwick Stokes" Subject: Classic timepieces reps Date: Thu, 02 Apr 2009 23:06:15 -0500 Message-Id: The new Porsche Design watches originated from the novel Titanium Chronogr= aph from the 1970's, an absolutely unique creation due to the perfection o= f its workmanship. Based on its design, the Porsche Design Company develop= ed an appealing, stylish, sporty and highly accurate watch. Unfortunately,= these timepieces come with a high price tag. http://kobodovud.cn/ That's why a clever group of European manufacturers decided to offer the s= ame exact functionality and style at greatly reduced prices: the Porsche D= esign replica watches. These replicas are so similar to the brand name pie= ces that it is practically impossible to tell them apart, other than by th= eir price. They look the same, they function the same and they definitely = don't have the same prices :) How would you like to browse through an amaz= ing collection of these watches and marvel yourself with their low prices?= Visit Diamond Replicas and see for yourself why sometimes replicas are so= much better than the originals! http://kobodovud.cn/ From owner-namedroppers@ops.ietf.org Fri Apr 3 11:46:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D146D28C2B5; Fri, 3 Apr 2009 11:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_55=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 lb8uUmzaDn5o; Fri, 3 Apr 2009 11:46:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEF6D28C2AE; Fri, 3 Apr 2009 11:46:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpoCO-000H48-Tx for namedroppers-data0@psg.com; Fri, 03 Apr 2009 18:33:04 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LpoCC-000H3P-5y for namedroppers@ops.ietf.org; Fri, 03 Apr 2009 18:33:01 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 99A4EA1037 for ; Fri, 3 Apr 2009 18:32:51 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] blast from the past X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 03 Apr 2009 18:32:51 +0000 Message-ID: <23977.1238783571@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: today i looked at http://www.nanog.org/meetings/nanog2/ and saw the following. "DNS Version 2"? Dropping packets with bad source addresses? DNS flooding? === NANOG Meeting Notes, 24-25 October, 1994 V2.0 Ann Arbor, Michigan ... After the break, Paul Vixie discussed the current status of the DNS and BIND. Specifically, he discusses DNS security. There are two reasons why DNS are not secure. There are two papers on this topic and they are both in the current BIND kit. So the information is freely available. Consider the case of telnetting across the Internet and getting what appears to be your machine's login banner. Doing a double check (host->address, then address->host) will help eliminate this problem. hosts.equiv and .rhosts are also sources of problems. Polluting the cache is a real problem. Doing UDP flooding is another problem. CERT says that doing rlogin is bad, but that does not solve the cache pollution problem. How to defend? 1. Validate the packets returned in a response to the query. Routers should drop UDP packets on which the source address don't match what it should be. (e.g. a udp packet comes in on a WAN link that should have come in via an ethernet interface).TCP is harder to spoof because of the three-way handshake, however running all DNS queries over TCP will add too much overhead to this process. 2. There are a number of static validations of packet format that can be done. Adding some kind of cryptographic information to the DNS would help. Unfortunately, this moves very slowly because there are a number of strong conflicting opinions. What is being done? The current BETA of BIND has almost everything fixed that can be fixed without a new protocol. Versions prior 4.9 are no longer supported. Paul may rewrite this server in the future, but it will still be called named because vendors have a hard time putting it into their releases if it is called something else. Paul is funded half-time by the Internet Software Consortium. Rick Adams funds it via UUNET's non-profit side. Rick did not want to put it under GNU. DNS version 2 is being discussed. This is due to the limit in the size of the udp packet. Paul M. and Paul V. are working to say something about this at the next IETF. HP, Sun, DEC and SGI are working with Paul to adopt the 4.9.3 BIND once it is productional. After this comes out, Paul will start working on other problems. One problem is the size of BIND in core. This change will include using the Berkeley db routing to feed this from a disk-based database. There will also be some effort for helping doing load-balancing better and perhaps implementing policy features. What about service issues? Providing name service is a start. DEC and SGI will be shipping BIND 4.9.3 will be shipping it with the next release. Paul has talked to Novell, but noone else....Novell has not been a helpful from the non-Unix side. === -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From jenny@alexworld.org Fri Apr 3 13:09:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89E23A6968 for ; Fri, 3 Apr 2009 13:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.76 X-Spam-Level: * X-Spam-Status: No, score=1.76 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 qpMdE6nYDCHz for ; Fri, 3 Apr 2009 13:09:26 -0700 (PDT) Received: from adsl-dyn253.78-99-194.t-com.sk (adsl-dyn253.78-99-194.t-com.sk [78.99.194.253]) by core3.amsl.com (Postfix) with SMTP id 5BBB93A6819 for ; Fri, 3 Apr 2009 13:09:20 -0700 (PDT) To: Subject: Bank account blocked From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090403200921.5BBB93A6819@core3.amsl.com> Date: Fri, 3 Apr 2009 13:09:20 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From orsten@akaentertainment.com Sat Apr 4 01:56:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE323A69C0 for ; Sat, 4 Apr 2009 01:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.636 X-Spam-Level: X-Spam-Status: No, score=-10.636 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 PkhlIK39tLrl for ; Sat, 4 Apr 2009 01:56:34 -0700 (PDT) Received: from ambia.co.jp (unknown [189.13.78.49]) by core3.amsl.com (Postfix) with SMTP id 1DA7E3A6991 for ; Sat, 4 Apr 2009 01:56:30 -0700 (PDT) To: Subject: Bank account overdraft From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090404085632.1DA7E3A6991@core3.amsl.com> Date: Sat, 4 Apr 2009 01:56:30 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From lagura@ambergrissolutions.com Sat Apr 4 12:01:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781603A685B for ; Sat, 4 Apr 2009 12:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 ZDJGt4t10v9N for ; Sat, 4 Apr 2009 12:01:31 -0700 (PDT) Received: from pool-72-71-245-111.cncdnh.fios.myfairpoint.net (pool-72-71-245-111.cncdnh.fios.myfairpoint.net [72.71.245.111]) by core3.amsl.com (Postfix) with SMTP id DF74D3A6891 for ; Sat, 4 Apr 2009 12:01:30 -0700 (PDT) To: Subject: Update - Credit card blocked From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090404190130.DF74D3A6891@core3.amsl.com> Date: Sat, 4 Apr 2009 12:01:30 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From lauthermanilal@agrega.com.ar Sat Apr 4 20:03:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185583A687C for ; Sat, 4 Apr 2009 20:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.187 X-Spam-Level: X-Spam-Status: No, score=-9.187 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_SUB_POOR_CREDIT=1.121, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 w3y+XCztgsxJ for ; Sat, 4 Apr 2009 20:03:24 -0700 (PDT) Received: from iei2.internetdsl.tpnet.pl (iei2.internetdsl.tpnet.pl [79.189.112.2]) by core3.amsl.com (Postfix) with SMTP id 3A6E93A67D1 for ; Sat, 4 Apr 2009 20:03:22 -0700 (PDT) To: Subject: Credit card balance transfer From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090405030323.3A6E93A67D1@core3.amsl.com> Date: Sat, 4 Apr 2009 20:03:22 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From milena.barros@andradecanellas.com.br Sat Apr 4 23:08:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD8D3A69FF for ; Sat, 4 Apr 2009 23:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 zyjRcxdj0Ab7 for ; Sat, 4 Apr 2009 23:08:52 -0700 (PDT) Received: from net145.181.94-158.dynamic.omskdom.ru (net145.181.94-158.dynamic.omskdom.ru [94.181.145.158]) by core3.amsl.com (Postfix) with SMTP id 3251C3A682F for ; Sat, 4 Apr 2009 23:08:40 -0700 (PDT) To: Subject: Credit card expiration date From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090405060842.3251C3A682F@core3.amsl.com> Date: Sat, 4 Apr 2009 23:08:40 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From jross@mem.net Sun Apr 5 02:31:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222EC3A683E; Sun, 5 Apr 2009 02:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.104 X-Spam-Level: X-Spam-Status: No, score=-44.104 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_SPEC_ROLEX_NOV5F=0.666, URIBL_BLACK=20, URIBL_SBL=20, 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 1JwWoI4ysTWH; Sun, 5 Apr 2009 02:31:31 -0700 (PDT) Received: from chewbacca.cableinet.co.uk (chewbacca.cableinet.co.uk [194.117.157.72]) by core3.amsl.com (Postfix) with SMTP id 9C18E3A67F1; Sun, 5 Apr 2009 02:30:45 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "Carrie Battle" To: "Elsie Cherry" Subject: Affordable brand name watches Date: Sun, 05 Apr 2009 05:31:47 -0500 Message-Id: What comes to mind when you hear the words Louis Vuitton? Of course, the c= lassic style, the superior quality of their bags, their unique look, and t= heir inflated price tag. But, how about being able to afford a beautiful L= ouis Vuitton handbag without having to dent your budget? It is now possibl= e. Thanks to Diamond Replicas, that Louis Vuitton bag or wallet is closer = to you than ever before! Come visit our new designer bag section and pick = that special Louis Vuitton handbag that you've always wanted. http://www.lironivop.cn Remember, Diamond Replicas offers award winning customer service and an ab= solute guarantee of its products and your privacy! http://www.lironivop.cn From nozomimrika@alliance.co.jp Sun Apr 5 10:47:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467DB3A6B34 for ; Sun, 5 Apr 2009 10:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.108 X-Spam-Level: X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 he6m9rxaTMOk for ; Sun, 5 Apr 2009 10:47:55 -0700 (PDT) Received: from adsl-068-153-174-074.sip.mia.bellsouth.net (adsl-068-153-174-074.sip.mia.bellsouth.net [68.153.174.74]) by core3.amsl.com (Postfix) with SMTP id A47593A69C2 for ; Sun, 5 Apr 2009 10:47:54 -0700 (PDT) To: Subject: Transaction disclosure report From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090405174754.A47593A69C2@core3.amsl.com> Date: Sun, 5 Apr 2009 10:47:54 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From manon@aktivdialog.de Sun Apr 5 12:42:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCFAC3A6988 for ; Sun, 5 Apr 2009 12:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 GiXRZO3uVqIX for ; Sun, 5 Apr 2009 12:41:56 -0700 (PDT) Received: from 189-041-63-244.xd-dynamic.ctbcnetsuper.com.br (189-041-63-244.xd-dynamic.ctbcnetsuper.com.br [189.41.63.244]) by core3.amsl.com (Postfix) with SMTP id 7F99A3A68C9 for ; Sun, 5 Apr 2009 12:41:52 -0700 (PDT) To: Subject: Personal loan information From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090405194153.7F99A3A68C9@core3.amsl.com> Date: Sun, 5 Apr 2009 12:41:52 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From supprefnum642@ebay.com Sun Apr 5 13:10:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533BC3A68F4; Sun, 5 Apr 2009 13:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.24 X-Spam-Level: X-Spam-Status: No, score=-15.24 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 1Y46vTqr2q6s; Sun, 5 Apr 2009 13:10:42 -0700 (PDT) Received: from 118-161-151-26.dynamic.hinet.net (118-161-151-26.dynamic.hinet.net [118.161.151.26]) by core3.amsl.com (Postfix) with SMTP id 1E83E3A6B34; Sun, 5 Apr 2009 13:10:36 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "James Atkins" To: "Sherri Carver" Subject: Cartier watches wholesale all year long! Date: Sun, 05 Apr 2009 16:11:38 -0500 Message-Id: What comes to mind when you hear the words Louis Vuitton? Of course, the c= lassic style, the superior quality of their bags, their unique look, and t= heir inflated price tag. But, how about being able to afford a beautiful L= ouis Vuitton handbag without having to dent your budget? It is now possibl= e. Thanks to Diamond Replicas, that Louis Vuitton bag or wallet is closer = to you than ever before! Come visit our new designer bag section and pick = that special Louis Vuitton handbag that you've always wanted. http://www.habexeciv.cn Remember, Diamond Replicas offers award winning customer service and an ab= solute guarantee of its products and your privacy! http://www.habexeciv.cn From keonbroglin@advantagewebcms.com Sun Apr 5 14:14:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C5E3A6B74 for ; Sun, 5 Apr 2009 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.48 X-Spam-Level: * X-Spam-Status: No, score=1.48 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, FH_HOST_EQ_DYNAMICIP=2.177, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 rLa0BsGAaLQB for ; Sun, 5 Apr 2009 14:14:31 -0700 (PDT) Received: from nv-74-4-141-34.dhcp.embarqhsd.net (nv-74-4-141-34.dhcp.embarqhsd.net [74.4.141.34]) by core3.amsl.com (Postfix) with SMTP id 1B6D33A6898 for ; Sun, 5 Apr 2009 14:14:29 -0700 (PDT) To: Subject: Credit card annual fee update From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090405211430.1B6D33A6898@core3.amsl.com> Date: Sun, 5 Apr 2009 14:14:29 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From mp2564@almourol.com Sun Apr 5 15:35:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227F93A67EA for ; Sun, 5 Apr 2009 15:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.636 X-Spam-Level: X-Spam-Status: No, score=-10.636 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 x3saQ2y9iLD8 for ; Sun, 5 Apr 2009 15:35:17 -0700 (PDT) Received: from accessticket.com (unknown [76.92.255.23]) by core3.amsl.com (Postfix) with SMTP id E9A593A684D for ; Sun, 5 Apr 2009 15:35:14 -0700 (PDT) To: Subject: Credit limit exceeded From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090405223515.E9A593A684D@core3.amsl.com> Date: Sun, 5 Apr 2009 15:35:14 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From mats.borgd@aicins.com Sun Apr 5 18:53:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063993A6781 for ; Sun, 5 Apr 2009 18:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.379 X-Spam-Level: ** X-Spam-Status: No, score=2.379 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_28=1.561, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 H78j-MEXVyu7 for ; Sun, 5 Apr 2009 18:53:29 -0700 (PDT) Received: from 84.122.94.6.dyn.user.ono.com (84.122.94.6.dyn.user.ono.com [84.122.94.6]) by core3.amsl.com (Postfix) with SMTP id 1A8CF3A6960 for ; Sun, 5 Apr 2009 18:53:27 -0700 (PDT) To: Subject: Transaction disclosure report From: MensHealth.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090406015328.1A8CF3A6960@core3.amsl.com> Date: Sun, 5 Apr 2009 18:53:27 -0700 (PDT)
Subscribe to Men's Health Today!



Subscribe to Men's Health Today!





To your health,


David Zinczenko
Editor-in-Chief
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Dept., 33 East Minor Street, Emmaus, PA 18098
From coleperk@gmail.com Mon Apr 6 09:54:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD023A6CC3; Mon, 6 Apr 2009 09:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.646 X-Spam-Level: X-Spam-Status: No, score=-19.646 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 HRY+qfJRBAXA; Mon, 6 Apr 2009 09:54:58 -0700 (PDT) Received: from HSI-KBW-078-042-035-077.hsi3.kabel-badenwuerttemberg.de (HSI-KBW-078-042-035-077.hsi3.kabel-badenwuerttemberg.de [78.42.35.77]) by core3.amsl.com (Postfix) with SMTP id BD3B53A6B04; Mon, 6 Apr 2009 09:54:49 -0700 (PDT) X-Originating-IP: 238.48.96.16 by smtp.78.42.35.77; Mon, 06 Apr 2009 16:52:52 -0100 Message-ID: <4645nps732861TVNCdhcwg-bounces@ietf.org> Date: Mon, 06 Apr 2009 12:55:52 -0500 From: "Homer Wilkins" To: "Homer Wilkins" Subject: Save thousands... no one will know Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Loving yourself is the first step in loving life. And what better way to do it, than by getting yourself a fine designer watch? http://www.habexeciv.cn How does 90 percent off sound? Great, of course! And greatness is what awaits you at Diam0nd Reps, the preferred online store where you will find the finest watch imitations for exactly that: 90% off! http://www.habexeciv.cn So, what are you waiting for? Get that unique timepiece today at Diam0nd Reps! From owner-namedroppers@ops.ietf.org Tue Apr 7 02:53:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2AB3A6823; Tue, 7 Apr 2009 02:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.217 X-Spam-Level: * X-Spam-Status: No, score=1.217 tagged_above=-999 required=5 tests=[AWL=-1.430, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, 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 zqk2xck38gJW; Tue, 7 Apr 2009 02:53:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E4E03A67AF; Tue, 7 Apr 2009 02:53:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lr7s7-000CPb-5r for namedroppers-data0@psg.com; Tue, 07 Apr 2009 09:45:35 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lr7s2-000CNZ-2H for namedroppers@psg.com; Tue, 07 Apr 2009 09:45:32 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 7881B3EC0B; Tue, 7 Apr 2009 13:45:28 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9YA1zUHnCrYG; Tue, 7 Apr 2009 13:45:28 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 4F0CC3EC0A for ; Tue, 7 Apr 2009 13:45:28 +0400 (MSD) Message-ID: <49DB20B8.7020505@cryptocom.ru> Date: Tue, 07 Apr 2009 13:45:28 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: namedroppers@psg.com Subject: [dnsext] New draft has been posted Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hello! Proposed draft for update DNSSec protocol in order to support GOST cryptographic algorithms in it has been posted to I-D repository. This work was done as a followup of discussions on the IETF meeting and dnssec-deployment mailing list where the necessity the minor protocol changes in order to support GOST cryptograpy was agreed upon. Draft has the name draft-dolmatov-dnsext-gost-dnssec-00.txt. We would like to have the WG adopt this document. Thanks in advance, dol@ ======== Basil Dolmatov Cryptocom Ltd. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From jroby@aena.es Tue Apr 7 09:50:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE523A6B72 for ; Tue, 7 Apr 2009 09:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.784 X-Spam-Level: X-Spam-Status: No, score=-73.784 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_DHCP=1.295, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, 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 aKWZ3IEF4CXF for ; Tue, 7 Apr 2009 09:50:33 -0700 (PDT) Received: from nc-67-238-167-210.dhcp.embarqhsd.net (nc-67-238-167-210.dhcp.embarqhsd.net [67.238.167.210]) by core3.amsl.com (Postfix) with SMTP id AD2263A6A99 for ; Tue, 7 Apr 2009 09:50:31 -0700 (PDT) To: Subject: Sweet NY From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090407165032.AD2263A6A99@core3.amsl.com> Date: Tue, 7 Apr 2009 09:50:31 -0700 (PDT) Teen Beautiful Blonde will get acquainted with good guy (or guys) for chat and real meetings!

My real Photo:

Click for mail me!

My E-mail: IgPX@zvdeeeev.com

 From michelle_stpierreh@advpayroll.com Tue Apr 7 12:18:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9482E3A6E2A for ; Tue, 7 Apr 2009 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.131 X-Spam-Level: X-Spam-Status: No, score=-78.131 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, 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 pU8Mkel6ODzr for ; Tue, 7 Apr 2009 12:18:21 -0700 (PDT) Received: from 80-218-133-163.dclient.hispeed.ch (80-218-133-163.dclient.hispeed.ch [80.218.133.163]) by core3.amsl.com (Postfix) with SMTP id 95AB328C13C for ; Tue, 7 Apr 2009 12:17:13 -0700 (PDT) To: Subject: Hey cute From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090407191715.95AB328C13C@core3.amsl.com> Date: Tue, 7 Apr 2009 12:17:13 -0700 (PDT) Teen Beautiful Blonde will get acquainted with good guy (or guys) for chat and real meetings!

My real Photo:

Click for mail me!

My E-mail: ps85@zcxvassfs.com

 From microbcor@advanced-connect.net Tue Apr 7 21:46:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70653A6830 for ; Tue, 7 Apr 2009 21:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.464 X-Spam-Level: X-Spam-Status: No, score=-65.464 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, 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 0oiRjH0qj8lu for ; Tue, 7 Apr 2009 21:46:36 -0700 (PDT) Received: from 201-34-31-253.pvoce701.dsl.brasiltelecom.net.br (201-34-31-253.pvoce701.dsl.brasiltelecom.net.br [201.34.31.253]) by core3.amsl.com (Postfix) with SMTP id 58CAC3A67CC for ; Tue, 7 Apr 2009 21:46:33 -0700 (PDT) To: Subject: Msg me From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090408044634.58CAC3A67CC@core3.amsl.com> Date: Tue, 7 Apr 2009 21:46:33 -0700 (PDT) I want to chat or meet you in real!
My real Photo:
Click for mail me!

My E-mail: aULt@zvdeeeev.com

 From lpvzj@alc-mg.com Wed Apr 8 06:22:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097223A6A3B for ; Wed, 8 Apr 2009 06:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.173 X-Spam-Level: X-Spam-Status: No, score=-22.173 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MINDSPRING=0.45, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MINDSPRING=2.2, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, 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 Fjg2tUHs6lnV for ; Wed, 8 Apr 2009 06:22:35 -0700 (PDT) Received: from user-1087ua7.cable.mindspring.com (user-1087ua7.cable.mindspring.com [64.131.249.71]) by core3.amsl.com (Postfix) with SMTP id D4CC128C19A for ; Wed, 8 Apr 2009 06:20:43 -0700 (PDT) To: Subject: itunes.com Invoice #93035 From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090408132044.D4CC128C19A@core3.amsl.com> Date: Wed, 8 Apr 2009 06:20:43 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From luau@abogadosargentinos.com Wed Apr 8 08:18:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572133A6A32 for ; Wed, 8 Apr 2009 08:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.448 X-Spam-Level: X-Spam-Status: No, score=-66.448 tagged_above=-999 required=5 tests=[AWL=14.781, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, SARE_URI_CONS9=1.666, 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 3zfvou-uDZFN for ; Wed, 8 Apr 2009 08:18:47 -0700 (PDT) Received: from aist.go.jp (unknown [189.71.150.210]) by core3.amsl.com (Postfix) with SMTP id 4D2BE3A69B7 for ; Wed, 8 Apr 2009 08:18:45 -0700 (PDT) To: Subject: Lets talk From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090408151846.4D2BE3A69B7@core3.amsl.com> Date: Wed, 8 Apr 2009 08:18:45 -0700 (PDT) I want to chat or meet you in real!
My real Photo:
Click for mail me!

My E-mail: BICU@sdfsdfwww.com

 From kevin.armstrong@ah.tvh.ca Wed Apr 8 12:24:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00EE03A6BAA for ; Wed, 8 Apr 2009 12:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.905 X-Spam-Level: X-Spam-Status: No, score=-87.905 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, 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 pCgzpargFmPQ for ; Wed, 8 Apr 2009 12:24:47 -0700 (PDT) Received: from agenatramp.fr (unknown [59.183.152.152]) by core3.amsl.com (Postfix) with SMTP id 2FDBE3A69C2 for ; Wed, 8 Apr 2009 12:24:42 -0700 (PDT) To: Subject: Why you dont take your phone? From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090408192444.2FDBE3A69C2@core3.amsl.com> Date: Wed, 8 Apr 2009 12:24:42 -0700 (PDT) I want to chat or meet you in real!
My real Photo:
Click for mail me!

My E-mail: 5TNS@zcxvassfs.com

 From owner-namedroppers@ops.ietf.org Wed Apr 8 16:49:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EF33A6BB0; Wed, 8 Apr 2009 16:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, 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 5aj2oBoV6yEl; Wed, 8 Apr 2009 16:49:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A10A43A6BA5; Wed, 8 Apr 2009 16:49:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrhO1-0009fP-W0 for namedroppers-data0@psg.com; Wed, 08 Apr 2009 23:40:54 +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 1LrhNl-0009dj-PN for namedroppers@psg.com; Wed, 08 Apr 2009 23:40:46 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n38NeZQu051494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2009 16:40:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 8 Apr 2009 16:40:33 -0700 To: namedroppers@psg.com From: Paul Hoffman Subject: [dnsext] Fwd: I-D ACTION:draft-dolmatov-dnsext-dnssec-gost-00.txt Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ...now posted. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC > Author(s) : V. Dolmatov, A. Chuprina, I. Ustinov > Filename : draft-dolmatov-dnsext-dnssec-gost-00.txt > Pages : 8 > Date : 2009-4-8 > >This document describes how to produce GOST signature and hash algorithms > DNSKEY and RRSIG resource records for use in the Domain Name System > Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-dolmatov-dnsext-dnssec-gost-00.txt -- to unsubscribe send a message to namedroppers-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 Apr 8 19:02:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB09A3A6A32; Wed, 8 Apr 2009 19:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.792 X-Spam-Level: X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=-0.297, 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 xvvoaD5vZrAg; Wed, 8 Apr 2009 19:02:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5FAD3A6A35; Wed, 8 Apr 2009 19:02:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrjWC-000GyC-KN for namedroppers-data0@psg.com; Thu, 09 Apr 2009 01:57:28 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrjVu-000Gwq-2p for namedroppers@psg.com; Thu, 09 Apr 2009 01:57:17 +0000 Received: from [192.168.1.104] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n391v7Km078520; Wed, 8 Apr 2009 21:57:07 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 8 Apr 2009 21:57:04 -0400 To: Paul Hoffman From: Edward Lewis Subject: Re: [dnsext] Fwd: I-D ACTION:draft-dolmatov-dnsext-dnssec-gost-00.txt Cc: namedroppers@psg.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The circumstances behind this draft have been discussed on non-IETF lists already, quite a few on this list have likely seen the messages. I support this being considered by the working group. I've seen a preview copy and it is very close, in form, to the RSA-SHA256 draft. At 16:40 -0700 4/8/09, Paul Hoffman wrote: >...now posted. > >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Use of GOST signature algorithms in DNSKEY >>and RRSIG Resource Records for DNSSEC >> Author(s) : V. Dolmatov, A. Chuprina, I. Ustinov >> Filename : draft-dolmatov-dnsext-dnssec-gost-00.txt >> Pages : 8 >> Date : 2009-4-8 >> >>This document describes how to produce GOST signature and hash algorithms >> DNSKEY and RRSIG resource records for use in the Domain Name System >> Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-dolmatov-dnsext-dnssec-gost-00.txt > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 9 01:50:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425733A6EBA; Thu, 9 Apr 2009 01:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.458 X-Spam-Level: * X-Spam-Status: No, score=1.458 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, 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 glFIv+f+UDhb; Thu, 9 Apr 2009 01:50:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7539A3A6B7A; Thu, 9 Apr 2009 01:50:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lrprq-000DCI-Ar for namedroppers-data0@psg.com; Thu, 09 Apr 2009 08:44:14 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lrprd-000DBb-9v for namedroppers@psg.com; Thu, 09 Apr 2009 08:44:07 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id A42673EC15; Thu, 9 Apr 2009 12:43:58 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2jCQM3jL0499; Thu, 9 Apr 2009 12:43:58 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 755483EC14 for ; Thu, 9 Apr 2009 12:43:58 +0400 (MSD) Message-ID: <49DDB54D.9040000@cryptocom.ru> Date: Thu, 09 Apr 2009 12:43:57 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: namedroppers@psg.com Subject: [dnsext] Re: New draft has been posted References: <49DB20B8.7020505@cryptocom.ru> In-Reply-To: <49DB20B8.7020505@cryptocom.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Sorry for misfiring, now it is available. Basil Dolmatov пишет: > Hello! > > Proposed draft for update DNSSec protocol in order to > support GOST cryptographic algorithms in it has been posted to I-D > repository. > === > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC > Author(s) : V. Dolmatov, A. Chuprina, I. Ustinov > Filename : draft-dolmatov-dnsext-dnssec-gost-00.txt > Pages : 8 > Date : 2009-4-8 > > This document describes how to produce GOST signature and hash algorithms > DNSKEY and RRSIG resource records for use in the Domain Name System > Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-dolmatov-dnsext-dnssec-gost-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ dol@ -- to unsubscribe send a message to namedroppers-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 Apr 9 07:09:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9207B3A6B86; Thu, 9 Apr 2009 07:09: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 PH6p1u4xFSgX; Thu, 9 Apr 2009 07:09:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 261F53A6782; Thu, 9 Apr 2009 07:09:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LrunV-0006LY-3Q for namedroppers-data0@psg.com; Thu, 09 Apr 2009 14:00:05 +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 1Lrun5-0006Js-Gv for namedroppers@psg.com; Thu, 09 Apr 2009 13:59:57 +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.3/8.14.3) with ESMTP id n39DxWfd023537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 15:59:32 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <49DDFF44.1070907@nlnetlabs.nl> Date: Thu, 09 Apr 2009 15:59:32 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Edward Lewis CC: Paul Hoffman , namedroppers@psg.com Subject: Re: [dnsext] Fwd: I-D ACTION:draft-dolmatov-dnsext-dnssec-gost-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 09 Apr 2009 15:59:33 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1, I intend to implement it. Best regards, Wouter Edward Lewis wrote: > The circumstances behind this draft have been discussed on non-IETF > lists already, quite a few on this list have likely seen the messages. > > I support this being considered by the working group. I've seen a > preview copy and it is very close, in form, to the RSA-SHA256 draft. > > At 16:40 -0700 4/8/09, Paul Hoffman wrote: >> ...now posted. >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Use of GOST signature algorithms in DNSKEY and >>> RRSIG Resource Records for DNSSEC >>> Author(s) : V. Dolmatov, A. Chuprina, I. Ustinov >>> Filename : draft-dolmatov-dnsext-dnssec-gost-00.txt >>> Pages : 8 >>> Date : 2009-4-8 >>> >>> This document describes how to produce GOST signature and hash >>> algorithms >>> DNSKEY and RRSIG resource records for use in the Domain Name System >>> Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-dolmatov-dnsext-dnssec-gost-00.txt >>> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknd/0QACgkQkDLqNwOhpPg43gCfQttI4WItwj8njx4hD4C6MBQH vEEAoK6rYnXv/Hyw7PRwP3snHh1cCisJ =VPlm -----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 jesquivel@anccar.com Thu Apr 9 13:53:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0943A67A1 for ; Thu, 9 Apr 2009 13:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.72 X-Spam-Level: X-Spam-Status: No, score=-80.72 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, 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 qqN5zhQEaO27 for ; Thu, 9 Apr 2009 13:53:14 -0700 (PDT) Received: from dsl5400B593.pool.t-online.hu (dsl5400B593.pool.t-online.hu [84.0.181.147]) by core3.amsl.com (Postfix) with SMTP id 153BE3A63C9 for ; Thu, 9 Apr 2009 13:53:12 -0700 (PDT) To: Subject: Why you dont take your phone? From: me MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090409205313.153BE3A63C9@core3.amsl.com> Date: Thu, 9 Apr 2009 13:53:12 -0700 (PDT) I want to chat or meet you in real!
My real Photo:
Click for mail me!

My E-mail: oFs0@zvdeeeev.com

 From m.gardner@amserve.com Sun Apr 12 05:48:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8343A69DB for ; Sun, 12 Apr 2009 05:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.155 X-Spam-Level: X-Spam-Status: No, score=-20.155 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, 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 FcBoA0urj4E5 for ; Sun, 12 Apr 2009 05:48:27 -0700 (PDT) Received: from amateurmatch.com (unknown [92.37.105.250]) by core3.amsl.com (Postfix) with SMTP id 416AA3A6999 for ; Sun, 12 Apr 2009 05:48:24 -0700 (PDT) To: Subject: Order Shipped -- Order #37472 From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090412124825.416AA3A6999@core3.amsl.com> Date: Sun, 12 Apr 2009 05:48:24 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From mjanu@aktis.cz Sun Apr 12 08:17:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA013A6B05 for ; Sun, 12 Apr 2009 08:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.489 X-Spam-Level: X-Spam-Status: No, score=-8.489 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, 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 4wrVaHevBmNk for ; Sun, 12 Apr 2009 08:17:30 -0700 (PDT) Received: from 82-169-54-75.ip.telfort.nl (82-169-54-75.ip.telfort.nl [82.169.54.75]) by core3.amsl.com (Postfix) with SMTP id EE6AE3A68C2 for ; Sun, 12 Apr 2009 08:17:27 -0700 (PDT) To: Subject: Sales Order walmart.com From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090412151727.EE6AE3A68C2@core3.amsl.com> Date: Sun, 12 Apr 2009 08:17:27 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@lists.ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From luis.m@adcb.com Sun Apr 12 12:56:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0A93A6802 for ; Sun, 12 Apr 2009 12:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.597 X-Spam-Level: X-Spam-Status: No, score=-14.597 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_RECV_IP_083028=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, 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 K+K9SBqkwTHz for ; Sun, 12 Apr 2009 12:56:48 -0700 (PDT) Received: from bdr145.neoplus.adsl.tpnet.pl (bdr145.neoplus.adsl.tpnet.pl [83.28.3.145]) by core3.amsl.com (Postfix) with SMTP id 1EDF23A679F for ; Sun, 12 Apr 2009 12:56:39 -0700 (PDT) To: Subject: Order Shipped -- Order #12178 From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090412195642.1EDF23A679F@core3.amsl.com> Date: Sun, 12 Apr 2009 12:56:39 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From miler@amberjack.stanford.edu Sun Apr 12 16:59:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10193A682B for ; Sun, 12 Apr 2009 16:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.213 X-Spam-Level: X-Spam-Status: No, score=-24.213 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, 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 GT+WwrteMZ3n for ; Sun, 12 Apr 2009 16:59:56 -0700 (PDT) Received: from aipai.net (unknown [201.2.142.1]) by core3.amsl.com (Postfix) with SMTP id F3B9F3A6C4E for ; Sun, 12 Apr 2009 16:59:02 -0700 (PDT) To: Subject: Customer Receipt/Purchase Confirmation From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090412235907.F3B9F3A6C4E@core3.amsl.com> Date: Sun, 12 Apr 2009 16:59:02 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From mzifraxphq@advf.com Mon Apr 13 00:38:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5904C3A6845 for ; Mon, 13 Apr 2009 00:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.919 X-Spam-Level: X-Spam-Status: No, score=-13.919 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 OxMMMv4S3skg for ; Mon, 13 Apr 2009 00:38:12 -0700 (PDT) Received: from amclub.org.sg (unknown [85.107.33.126]) by core3.amsl.com (Postfix) with SMTP id 349533A6359 for ; Mon, 13 Apr 2009 00:38:01 -0700 (PDT) To: Subject: Sales Order walmart.com From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090413073802.349533A6359@core3.amsl.com> Date: Mon, 13 Apr 2009 00:38:01 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From nunez@alexmann.com Mon Apr 13 02:21:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD413A6D21 for ; Mon, 13 Apr 2009 02:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.227 X-Spam-Level: X-Spam-Status: No, score=-8.227 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 Nj7dk0+x-TKj for ; Mon, 13 Apr 2009 02:21:43 -0700 (PDT) Received: from 20151041040.user.veloxzone.com.br (20151041040.user.veloxzone.com.br [201.51.41.40]) by core3.amsl.com (Postfix) with SMTP id C389A3A6CEE for ; Mon, 13 Apr 2009 02:21:39 -0700 (PDT) To: Subject: Customer Receipt/Purchase Confirmation From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090413092140.C389A3A6CEE@core3.amsl.com> Date: Mon, 13 Apr 2009 02:21:39 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From kgran@agrinutrition.com Mon Apr 13 03:00:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB173A6D37 for ; Mon, 13 Apr 2009 03:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.499 X-Spam-Level: ** X-Spam-Status: No, score=2.499 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 Dx29U5XjyjHz for ; Mon, 13 Apr 2009 03:00:03 -0700 (PDT) Received: from 73.218.46.84.ip.erdves.lt (73.218.46.84.ip.erdves.lt [84.46.218.73]) by core3.amsl.com (Postfix) with SMTP id CD3603A6D2F for ; Mon, 13 Apr 2009 02:59:57 -0700 (PDT) To: Subject: Email Handling Opinion Needed From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090413100000.CD3603A6D2F@core3.amsl.com> Date: Mon, 13 Apr 2009 02:59:57 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Mon Apr 13 13:08:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00423A6924; Mon, 13 Apr 2009 13:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 A6++Um3ldnm4; Mon, 13 Apr 2009 13:08:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 714633A686D; Mon, 13 Apr 2009 13:08:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtSKJ-000Nev-MB for namedroppers-data0@psg.com; Mon, 13 Apr 2009 20:00:19 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtSK6-000NdR-AF for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 20:00:13 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 533812FEA3D7 for ; Mon, 13 Apr 2009 20:00:04 +0000 (UTC) Date: Mon, 13 Apr 2009 16:00:02 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request Message-ID: <20090413200002.GB24286@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, I hereby post the attached template for public review, under the terms of RFC 5395. This posting begins the formal comment period under section 3.1.1 (1) in RFC 5395. Due to the unavailability of others, I'll be the expert performing this review. Please provide any comments you have on the proposal by 17:00 EDT on 2009-05-04. I may not be able to consider comments received after that time. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=US-ASCII; name="sslfp-rr-request.txt" Content-Disposition: attachment; filename="sslfp-rr-request.txt" Content-Transfer-Encoding: base64 DQoNCkEuICAgIFN1Ym1pc3Npb24gRGF0ZToNCg0KICAgICAgICAgMjAwOS0wMi0yNQ0KDQog ICBCLiAgICBTdWJtaXNzaW9uIFR5cGU6DQoNCiAgICAgICAgIFtYXSBOZXcgUlJUWVBFDQog ICAgICAgICBbIF0gTW9kaWZpY2F0aW9uIHRvIGV4aXN0aW5nIFJSVFlQRQ0KDQogICBDLiAg ICBDb250YWN0IEluZm9ybWF0aW9uIGZvciBzdWJtaXR0ZXI6DQoNCiAgICAgICAgICAgIE5h bWU6IE9uZHJlaiBTdXJ5DQogICAgICAgICAgICBFbWFpbCBBZGRyZXNzOiBvbmRyZWouc3Vy eUBuaWMuY3oNCiAgICAgICAgICAgIEludGVybmF0aW9uYWwgdGVsZXBob25lIG51bWJlcjog KzQyMDIyMjc0NTExMA0KICAgICAgICAgICAgT3RoZXIgY29udGFjdCBoYW5kbGVzOiBuL2EN Cg0KICAgRC4gICAgTW90aXZhdGlvbiBmb3IgdGhlIG5ldyBSUlRZUEUgYXBwbGljYXRpb24/ DQoNCiAgICAgICAgIFRoZXJlIGlzIGEgbmVlZCB0byBwdWJsaXNoIGEgcHVibGljIGtleSBp bmZvcm1hdGlvbiBpbiBETlMsIHdoaWNoDQogICAgICAgICB3b3VsZCBwcm92aWRlIHN1ZmZp Y2llbnQgdHJ1c3QgdG8gYWxsb3cgYW4gYXV0aGVudGljYXRpb24gb2YgYQ0KICAgICAgICAg c2VydmVyIHNpZGUgcHVibGljIGtleS4gIFRoZXJlIGlzIGEgbmVlZCB0byBpbmRpY2F0ZSB0 aGF0IGEgc2VjdXJlDQogICAgICAgICBjb25uZWN0aW9uIHRvIGEgc2VydmljZSBpcyBtYW5k YXRvcnkuICBEYXRhIGluY2x1ZGVkIGluIHRoaXMgbmV3DQogICAgICAgICBSUlRZUEUgdG9n ZXRoZXIgd2l0aCB0aGUgRE5TU0VDIHdpbGwgY3JlYXRlIGEgc2VjdXJlIGNoYWluIGxlYWRp bmcNCiAgICAgICAgIHRvIGVzdGFibGlzaGluZyBhIHNlY3VyZWQgY29ubmVjdGlvbiBmcm9t IGEgY2xpZW50IChzdWNoIGFzIGEgd2ViDQogICAgICAgICBicm93c2VyKSB0byBhIHNlcnZl ci4gIE5ldyBSUlRZUEUgd2lsbCBpbmNsdWRlIGEgZmxhZyB0byBpbmRpY2F0ZQ0KICAgICAg ICAgdGhhdCBhIHNlY3VyZSBjb25uZWN0aW9uIHRvIGEgc3BlY2lmaWVkIHNlcnZpY2UgaXMg cmVxdWlyZWQuICBOb3RlDQogICAgICAgICB0aGlzIG5ldyBSUlRZUEUgaXMgYSBnZW5lcmlj IHRvIGFsbCBwcm90b2NvbHMgYW5kIHNlcnZpY2VzLg0KDQogICBFLiAgICBEZXNjcmlwdGlv biBvZiB0aGUgcHJvcG9zZWQgUlIgdHlwZS4NCg0KICAgICAgICAgSGVyZSBpcyB0aGUgZm9y bWF0IG9mIHRoZSBwcm9wb3NlZCBSUiB0eXBlOg0KDQogICAgICAgICBfU2VydmljZS5fUHJv dG8uTmFtZSBUVEwgQ2xhc3MgVExTRlAgUG9ydCBNYW5kYXRvcnkgUHViS2V5QWxnbyBIYXNo QWxnbyBGaW5nZXJQcmludA0KDQogICAgICAgICBTZXJ2aWNlDQogICAgICAgICAgICAgICAg VGhlIHN5bWJvbGljIG5hbWUgb2YgdGhlIGRlc2lyZWQgc2VydmljZSBhcyBkZWZpbmVkIGlu DQogICAgICAgICAgICAgICAgW1JGQzI3ODJdLg0KDQogICAgICAgICBQcm90bw0KICAgICAg ICAgICAgICAgIFRoZSBzeW1ib2xpYyBuYW1lIG9mIHRoZSBkZXNpcmVkIHByb3RvY29sIGFz IGRlZmluZWQgaW4NCiAgICAgICAgICAgICAgICBbUkZDMjc4Ml0uDQoNCiAgICAgICAgIFBv cnQNCiAgICAgICAgICAgICAgICBUQ1AvVURQIHBvcnQgbnVtYmVyIHdoZXJlIGNsaWVudCBz aG91bGQgZXN0YWJsaXNoDQogICAgICAgICAgICAgICAgY29ubmVjdGlvbi4gVGhpcyBpcyAx NiBiaXQgdW5zaWduZWQgbnVtYmVyLg0KDQogICAgICAgICBNYW5kYXRvcnkNCiAgICAgICAg ICAgICAgICBNYW5kYXRvcnkgYml0IGRlZmluZXMgaWYgYSBzZWN1cmVkIGNvbm5lY3Rpb24g dG8gdGhlIGhvc3QNCiAgICAgICAgICAgICAgICBpcyBtYW5kYXRvcnkuICBUaGlzIGlzIDEg Yml0IG51bWJlciBwYWRkZWQgd2l0aCB6ZXJvZXMgdG8gOA0KICAgICAgICAgICAgICAgIGJp dHMuDQoNCiAgICAgICAgIFB1YktleUFsZ28NCiAgICAgICAgICAgICAgICBUaGUgYWxnb3Jp dGhtIG9mIHRoZSBwdWJsaWMga2V5LiAgVGhpcyBpcyA4IGJpdCB1bnNpZ25lZA0KICAgICAg ICAgICAgICAgIG51bWJlci4NCg0KICAgICAgICAgSGFzaEFsZ28NCg0KICAgICAgICAgICAg ICAgIFRoZSBhbGdvcml0aG0gdXNlZCB0byBjYWxjdWxhdGUgZmluZ2VycHJpbnQgaGFzaC4g IFRoaXMgaXMNCiAgICAgICAgICAgICAgICA4IGJpdCB1bnNpZ25lZCBudW1iZXIuDQoNCiAg ICAgICAgIEZpbmdlclByaW50DQogICAgICAgICAgICAgICAgVGhlIGZpbmdlcnByaW50IG9m IHRoZSBwdWJsaWMga2V5Lg0KDQoNCiAgICAgICAgIFRydW5jYXRpb24gaXMgbm90IGFsbG93 ZWQuDQoNCiAgIEYuICAgIFdoYXQgZXhpc3RpbmcgUlJUWVBFIG9yIFJSVFlQRXMgY29tZSBj bG9zZXN0IHRvIGZpbGxpbmcgdGhhdA0KICAgICAgICAgbmVlZCBhbmQgd2h5IGFyZSB0aGV5 IHVuc2F0aXNmYWN0b3J5Pw0KDQogICAgICAgICBTU0hGUCBSUlRZUEUgaXMgc2ltaWxhciwg YnV0IGxpbWl0ZWQgb25seSB0byB0aGUgU1NIIHByb3RvY29sLg0KDQogICBHLiAgICBXaGF0 IG1uZW1vbmljIGlzIHJlcXVlc3RlZCBmb3IgdGhlIG5ldyBSUlRZUEUgKG9wdGlvbmFsKT8N Cg0KICAgICAgICAgVExTRlANCg0KICAgSC4gICAgRG9lcyB0aGUgcmVxdWVzdGVkIFJSVFlQ RSBtYWtlIHVzZSBvZiBhbnkgZXhpc3RpbmcgSUFOQQ0KICAgICAgICAgUmVnaXN0cnkgb3Ig cmVxdWlyZSB0aGUgY3JlYXRpb24gb2YgYSBuZXcgSUFOQSBzdWItcmVnaXN0cnkgaW4NCiAg ICAgICAgIEROUyBQYXJhbWV0ZXJzPw0KDQogICAgICAgICBETlMgU2VjdXJpdHkgUmVnaXN0 cnkgQWxnb3JpdGhtIE51bWJlcnMgZm9yIFB1YktleUFsZ28NCiAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZG5zLXNlYy1hbGctbnVtYmVycy9kbnMtc2Vj LWFsZy1udW1iZXJzLnhodG1sDQogICAgICAgICBEaWdlc3QgQWxnb3JpdGhtcyBSZWdpc3Ry eSBmb3IgSGFzaEFsZ28NCiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMvZHMtcnItdHlwZXMvZHMtcnItdHlwZXMueGh0bWwNCg0KICAgSS4gICAgRG9lcyB0 aGUgcHJvcG9zYWwgcmVxdWlyZS9leHBlY3QgYW55IGNoYW5nZXMgaW4gRE5TDQogICAgICAg ICBzZXJ2ZXJzL3Jlc29sdmVycyB0aGF0IHByZXZlbnQgdGhlIG5ldyB0eXBlIGZyb20gYmVp bmcNCiAgICAgICAgIHByb2Nlc3NlZCBhcyBhbiB1bmtub3duIFJSVFlQRSAoc2VlIFtSRkMz NTk3XSk/DQoNCiAgICAgICAgIE5vLg0KDQogICBKLiAgICBDb21tZW50czoNCg0KICAgICAg ICAgTm9uZS4NCg== --oLBj+sq0vYjzfsbl-- -- to unsubscribe send a message to namedroppers-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 Apr 13 13:09:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4F43A6C05; Mon, 13 Apr 2009 13:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 R+0C1tqkhzWw; Mon, 13 Apr 2009 13:09:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1DD923A686D; Mon, 13 Apr 2009 13:09:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtSQ6-000NxA-Hq for namedroppers-data0@psg.com; Mon, 13 Apr 2009 20:06:18 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtSPt-000NwI-Lh for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 20:06:11 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2DE522FEA3D7 for ; Mon, 13 Apr 2009 20:06:04 +0000 (UTC) Date: Mon, 13 Apr 2009 16:06:02 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Request for adoption (was: [dnsext] New draft has been posted) Message-ID: <20090413200602.GC24286@shinkuro.com> References: <49DB20B8.7020505@cryptocom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49DB20B8.7020505@cryptocom.ru> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, This is a request that WG members to express their opinion as to whether draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG item. We have already had two expressions to the mailing list explicitly expressing support for the adoption of the document. Remember that we must have the commitment of at least five (5) people willing to adopt the document, and to review it. In practice, it is better to have more than five people, since we require at least five supportive reviews in order to send the document on to the IESG. If we can't get five people to say something is a good idea, it is probably not a candidate for IETF standardization. Best regards, Andrew (for the Chairs) On Tue, Apr 07, 2009 at 01:45:28PM +0400, Basil Dolmatov wrote: > Hello! > > Proposed draft for update DNSSec protocol in order to > support GOST cryptographic algorithms in it has been posted to I-D > repository. [&c.] -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 13 13:46:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2213A6858; Mon, 13 Apr 2009 13:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 Xe5QpjoX95I0; Mon, 13 Apr 2009 13:46:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 662AB3A67D8; Mon, 13 Apr 2009 13:46:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtSzT-0000En-51 for namedroppers-data0@psg.com; Mon, 13 Apr 2009 20:42:51 +0000 Received: from [209.85.220.162] (helo=mail-fx0-f162.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtSz9-0000Dg-37 for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 20:42:42 +0000 Received: by fxm6 with SMTP id 6so2304250fxm.41 for ; Mon, 13 Apr 2009 13:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.211 with SMTP id g19mr1472911fap.39.1239655348197; Mon, 13 Apr 2009 13:42:28 -0700 (PDT) In-Reply-To: <20090413200602.GC24286@shinkuro.com> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Mon, 13 Apr 2009 22:42:28 +0200 Message-ID: Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: DNSEXT WG Content-Type: multipart/alternative; boundary=001636c5a717ac598f046775c0f2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --001636c5a717ac598f046775c0f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I have read the draft and support the adoption. Ondrej. On Mon, Apr 13, 2009 at 10:06 PM, Andrew Sullivan wrote: > Dear colleagues, > > This is a request that WG members to express their opinion as to whether > draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG > item. > > We have already had two expressions to the mailing list explicitly > expressing support for the adoption of the document. > > Remember that we must have the commitment of at least five (5) people > willing to adopt the document, and to review it. In practice, it is > better to have more than five people, since we require at least five > supportive reviews in order to send the document on to the IESG. If > we can't get five people to say something is a good idea, it is > probably not a candidate for IETF standardization. > > Best regards, > > Andrew (for the Chairs) > > On Tue, Apr 07, 2009 at 01:45:28PM +0400, Basil Dolmatov wrote: > > Hello! > > > > Proposed draft for update DNSSec protocol in order to > > support GOST cryptographic algorithms in it has been posted to I-D > > repository. > > [&c.] > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- --001636c5a717ac598f046775c0f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have read the draft and support the adoption.

Ondrej.

On Mon, Apr 13, 2009 at 10:06 PM, Andrew Sullivan <ajs@shinkuro.com= > wrote:
Dear colleagues,<= br>
This is a request that WG members to express their opinion as to whether draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG
item.

We have already had two expressions to the mailing list explicitly
expressing support for the adoption of the document.

Remember that we must have the commitment of at least five (5) people
willing to adopt the document, and to review it. =C2=A0In practice, it is better to have more than five people, since we require at least five
supportive reviews in order to send the document on to the IESG. =C2=A0If we can't get five people to say something is a good idea, it is
probably not a candidate for IETF standardization.

Best regards,

Andrew (for the Chairs)

On Tue, Apr 07, 2009 at 01:45:28PM +0400, Basil Dolmatov wrote:
> Hello!
>
> Proposed draft for update DNSSec protocol in order to
> support GOST cryptographic algorithms in it has been posted to I-D
> repository.

[&c.]

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>



--
Ondrej Sury
= technicky reditel/Chief Technical Officer
----------------------------= -------------
CZ.NIC, z.s.p.o. =C2=A0-- =C2=A0.cz domain registry
A= mericka 23,120 00 Praha 2,Czech Republic
mailto:ondrej.sury@nic.cz =C2=A0= http://nic.cz/
sip:ondrej.sury@nic.cz tel:+420.222745110
mob:+4= 20.739013699 =C2=A0 =C2=A0 fax:+420.222745112
-----------------------------------------


--001636c5a717ac598f046775c0f2-- -- to unsubscribe send a message to namedroppers-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 Apr 13 13:47:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D61B3A68E3; Mon, 13 Apr 2009 13:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 92WFOsO33CnT; Mon, 13 Apr 2009 13:47:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 334813A67D8; Mon, 13 Apr 2009 13:47:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtT1l-0000Pa-NC for namedroppers-data0@psg.com; Mon, 13 Apr 2009 20:45:13 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtT1Y-0000Nt-JN for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 20:45:07 +0000 Received: from [10.31.200.240] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3DKirJu030207; Mon, 13 Apr 2009 16:44:53 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090413200002.GB24286@shinkuro.com> References: <20090413200002.GB24286@shinkuro.com> Date: Mon, 13 Apr 2009 16:44:32 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-972467003==_ma============" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --============_-972467003==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" So, it's like this? hostname.example.tld. AAAA 2003:82BF:9E21::CAFE:BEEF _http._tcp.hostname.example.tld. TLSFP 80 0 5 1 F6CD025B3F5D03040895 ( 05354A0115584B56D683 ) _http._tcp.hostname.example.tld. TLSFP 80 0 5 1 584B56D683F6CD025B3F ( 5D0304089505354A0115 ) _ssh._tcp.hostname.example.tld. TLSFP 22 1 2 1 123456789abcdef67890 ) 123456789abcdef67890 ( (latter instead of) _ssh._tcp.hostname.example.tld. SSHFP 2 1 123456789abcdef67890 ) 123456789abcdef67890 ( Positioning this as an improvement on the SRV record is certainly more promising that this old proposal to extend the KEY RR (http://www.potaroo.net/ietf/all-ids/draft-lewis-dnsext-key-genprot-00.txt). I mention the latter because it was part of the SYKED BOF, which tried to organize the three proposals to put application keys into the DNS - the SSH proposal which did make it to an RFC, a proposal for IPSEC which also went to RFC were the other two. The KEY RR generic was dropped. The "con" to the idea was the thought of putting too much emphasis on the security of DNSSEC, i.e., if the DNS key was mangled, other protocols could then be mangled. I don't know if I really buy that argument, but it was the big hit SYKED took from the Security Area. But SSH and IPSECKEY (the WG name) got specific key proposals through. I think it's a good idea, I think the discussion is over the security models of the applications and how much fate sharing they can take with DNSSEC. At 16:00 -0400 4/13/09, Andrew Sullivan wrote: >Dear colleagues, > >I hereby post the attached template for public review, under the terms >of RFC 5395. This posting begins the formal comment period under >section 3.1.1 (1) in RFC 5395. > >Due to the unavailability of others, I'll be the expert performing >this review. > >Please provide any comments you have on the proposal by 17:00 EDT on >2009-05-04. I may not be able to consider comments received after >that time. > >Best regards, > >Andrew > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. > >Attachment converted: Macintosh HD:sslfp-rr-request.txt (TEXT/ttxt) (00348806) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. --============_-972467003==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE R
So, it's like this?

hostname.example.tld.            AAAA  2003:82BF:9E21::CAFE:BEEF
_http._tcp.hostname.example.tld. TLSFP 80 0 5 1 F6CD025B3F5D03040895 (
                                                05354A0115584B56D683 )
_http._tcp.hostname.example.tld. TLSFP 80 0 5 1 584B56D683F6CD025B3F (
                                                5D0304089505354A0115 )
_ssh._tcp.hostname.example.tld.  TLSFP 22 1 2 1 123456789abcdef67890 )
                                                123456789abcdef67890 (
(latter instead of)
_ssh._tcp.hostname.example.tld.  SSHFP 2 1 123456789abcdef67890 )
                                           123456789abcdef67890 (

Positioning this as an improvement on the SRV record is certainly more promising that this old proposal to extend the KEY RR (http://www.potaroo.net/ietf/all-ids/draft-lewis-dnsext-key-genprot-00.txt).  I mention the latter because it was part of the SYKED BOF, which tried to organize the three proposals to put application keys into the DNS - the SSH proposal which did make it to an RFC, a proposal for IPSEC which also went to RFC were the other two.  The KEY RR generic was dropped.

The "con" to the idea was the thought of putting too much emphasis on the security of DNSSEC, i.e., if the DNS key was mangled, other protocols could then be mangled.  I don't know if I really buy that argument, but it was the big hit SYKED took from the Security Area.  But SSH and IPSECKEY (the WG name) got specific key proposals through.

I think it's a good idea, I think the discussion is over the security models of the applications and how much fate sharing they can take with DNSSEC.

At 16:00 -0400 4/13/09, Andrew Sullivan wrote:
>Dear colleagues,
>
>I hereby post the attached template for public review, under the terms
>of RFC 5395.  This posting begins the formal comment period under
>section 3.1.1 (1) in RFC 5395.
>
>Due to the unavailability of others, I'll be the expert performing
>this review.
>
>Please provide any comments you have on the proposal by 17:00 EDT on
>2009-05-04.  I may not be able to consider comments received after
>that time.
>
>Best regards,
>
>Andrew
>
>--
>Andrew Sullivan
>ajs@shinkuro.com
>Shinkuro, Inc.
>
>Attachment converted: Macintosh HD:sslfp-rr-request.txt (TEXT/ttxt) (00348806)

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.
--============_-972467003==_ma============-- -- to unsubscribe send a message to namedroppers-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 Apr 13 13:48:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0027C3A6858; Mon, 13 Apr 2009 13:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.454, 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 lNEW9MPn1fLu; Mon, 13 Apr 2009 13:48:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2A8DE3A67D8; Mon, 13 Apr 2009 13:48:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtT2M-0000Sd-2L for namedroppers-data0@psg.com; Mon, 13 Apr 2009 20:45:50 +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 1LtT1x-0000QZ-Ty for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 20:45:32 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DKjNYs059801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 13:45:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090413200602.GC24286@shinkuro.com> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Mon, 13 Apr 2009 13:45:22 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 4:06 PM -0400 4/13/09, Andrew Sullivan wrote: >This is a request that WG members to express their opinion as to whether >draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG >item. Yes, including the review requirement. --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 Apr 13 14:10:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B393A6924; Mon, 13 Apr 2009 14:10:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char DE hex): Cc: Ond\336ej Sur\230 ) id 1LtTLH-0001pX-6X for namedroppers-data0@psg.com; Mon, 13 Apr 2009 21:05:23 +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 1LtTL0-0001n5-GO for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 21:05:14 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DL50r8060974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 14:05:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090413200002.GB24286@shinkuro.com> References: <20090413200002.GB24286@shinkuro.com> Date: Mon, 13 Apr 2009 14:04:59 -0700 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request Cc: OndÞej Sur˜ Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This application is OK as it stands. I propose some changes that the proposer may or may not like. None of the proposed changes would cause the proposal to be rejected, but changing them now would mean that a later revision would not be needed. a) The name should be something other than "TLSFP" because the RRTYPE definition is not limited to TLS. Something like "PKFP" better matches the description. b) The description should at least mention the fact that the public key listed in the RRTYPE might not be the public key used by the responder at Service.Proto.Port.Name. That is, even if a signed record says that the public key for _pop._tcp.110.popserver.example.com is KeyA, that server might still offer KeyB in a certificate that the user would trust based on a different trust chain than the DNSSEC trust chain. This is quite an important distinction; without it, this RRTYPE description hints that *only* the named key that will be found at the given location. --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 lee6darrell@4thebank.com Mon Apr 13 14:59:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A623A6A13 for ; Mon, 13 Apr 2009 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.592 X-Spam-Level: **** X-Spam-Status: No, score=4.592 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 vShEeM00cpsc for ; Mon, 13 Apr 2009 14:59:31 -0700 (PDT) Received: from 189-015-121-158.xd-dynamic.ctbcnetsuper.com.br (189-015-121-158.xd-dynamic.ctbcnetsuper.com.br [189.15.121.158]) by core3.amsl.com (Postfix) with SMTP id 4B0D23A6C54 for ; Mon, 13 Apr 2009 14:59:27 -0700 (PDT) To: Subject: Sales Receipt Amazon From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090413215928.4B0D23A6C54@core3.amsl.com> Date: Mon, 13 Apr 2009 14:59:27 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Mon Apr 13 15:26:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68A83A67F4; Mon, 13 Apr 2009 15:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 NBKUpHqGfwFY; Mon, 13 Apr 2009 15:26:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 114CD3A67ED; Mon, 13 Apr 2009 15:26:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtUWg-00063o-PF for namedroppers-data0@psg.com; Mon, 13 Apr 2009 22:21:14 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtUWU-00062I-67 for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 22:21:08 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 787382FEA3D7 for ; Mon, 13 Apr 2009 22:20:58 +0000 (UTC) Date: Mon, 13 Apr 2009 18:20:56 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: TLSFP! Not SSLFP! (was: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request) Message-ID: <20090413222056.GD24286@shinkuro.com> References: <20090413200002.GB24286@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090413200002.GB24286@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, Because I am addle-minded, I put the wrong requested mnemonic in the subject line originally. My apologies to all, and my thanks to Paul Vixie who applied the first clue-stick. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 13 16:02:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F23728C195; Mon, 13 Apr 2009 16:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-1.154, 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 8k9GAgfVp3IA; Mon, 13 Apr 2009 16:02:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0653728C19A; Mon, 13 Apr 2009 16:01:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtV6A-0007vz-4f for namedroppers-data0@psg.com; Mon, 13 Apr 2009 22:57:54 +0000 Received: from [209.85.132.246] (helo=an-out-0708.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtV5s-0007ud-NR for namedroppers@ops.ietf.org; Mon, 13 Apr 2009 22:57:47 +0000 Received: by an-out-0708.google.com with SMTP id c37so1414649anc.26 for ; Mon, 13 Apr 2009 15:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AZWAfZrf251RfM+SStZXzsuJ+erbd3t3eVL0U4H/OfE=; b=tXGnah+nByORH/MFCOsVK7txwE5Jn3wI+Xz0U9R40Y6Loq7bH67W5bblIcIwy5c6lT UEPRl7ZYVjxSQRMJo9L1aG00WqKHvwzw8H4dm//Gr31q4KmDIw/okMg9ey2S1MT7hRyj v4cTKhyWvxteV87H2UjckQ6Hpr8Z1NXbG8sN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XI20G2s5mVbQW+gUiIwxPWI1HmvjxnwNilHnLw59YhEWkAMmdvoPCQCKjH9arYvRF4 bMbVd2Wh/wYGW6Sp8boycFwPD1jgylH7sy6I8WoT2bM3zzrx3a7X+hV6Z0mbAfUgT6ik JQtRynu9RIW8fOn/th7RtuOImZYECg9J4SY7M= MIME-Version: 1.0 Received: by 10.100.251.14 with SMTP id y14mr8745698anh.40.1239663455200; Mon, 13 Apr 2009 15:57:35 -0700 (PDT) In-Reply-To: References: <20090413200002.GB24286@shinkuro.com> Date: Mon, 13 Apr 2009 18:57:35 -0400 Message-ID: <1028365c0904131557s56ef59d7o465e032604b3269c@mail.gmail.com> Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request From: Donald Eastlake To: =?windows-1252?Q?Ond=DEej_Sur=98?= Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In the same spirit of improvement as Paul's message, to provide future flexibility, I suggest the "Mandatory" byte, which now has only two valid byte values, be renamed "Flags" or the like with one flag bit indicating mandatory and the other as must be set to zero and ignored on receipt. Thanks, Donald On Mon, Apr 13, 2009 at 5:04 PM, Paul Hoffman wrote= : > This application is OK as it stands. I propose some changes that the prop= oser may or may not like. None of the proposed changes would cause the prop= osal to be rejected, but changing them now would mean that a later revision= would not be needed. > > a) The name should be something other than "TLSFP" because the RRTYPE def= inition is not limited to TLS. Something like "PKFP" better matches the des= cription. > > b) The description should at least mention the fact that the public key l= isted in the RRTYPE might not be the public key used by the responder at Se= rvice.Proto.Port.Name. That is, even if a signed record says that the publi= c key for _pop._tcp.110.popserver.example.com is KeyA, that server might st= ill offer KeyB in a certificate that the user would trust based on a differ= ent trust chain than the DNSSEC trust chain. This is quite an important dis= tinction; without it, this RRTYPE description hints that *only* the named k= ey that will be found at the given location. > > > --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: > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.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 Tue Apr 14 11:37:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9563A6E50; Tue, 14 Apr 2009 11:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 VjdQQgXQwQWq; Tue, 14 Apr 2009 11:37:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 221F93A6B06; Tue, 14 Apr 2009 11:37:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtnOL-00028m-Hd for namedroppers-data0@psg.com; Tue, 14 Apr 2009 18:29:53 +0000 Received: from [131.107.115.215] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtnO7-00027C-VM for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 18:29:46 +0000 Received: from tk5-exmlt-c102.redmond.corp.microsoft.com (157.54.24.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 14 Apr 2009 11:29:39 -0700 Received: from NA-EXMSG-C115.redmond.corp.microsoft.com ([157.54.61.161]) by tk5-exmlt-c102.redmond.corp.microsoft.com ([157.54.24.67]) with mapi; Tue, 14 Apr 2009 11:29:39 -0700 From: Dan Simon To: Andrew Sullivan , "namedroppers@ops.ietf.org" Date: Tue, 14 Apr 2009 11:29:37 -0700 Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Thread-Topic: Request for adoption (was: [dnsext] New draft has been posted) Thread-Index: Acm8c4xcPjN9k9nHQ0eYIzDnwitoKgAuxIkg Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> In-Reply-To: <20090413200602.GC24286@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Does the WG have any formal statement of criteria by which it will judge th= is and future proposals to add algorithms to the DNSSEC standard? If not, = then perhaps it should. I'm concerned in particular about two dangers: 1) The proliferation of "vanity algorithms": Because DNSSEC is expected t= o become an extremely widely used standard, it's also an ideal conduit for = entities (national governments or even enterprises) that wish for one reaso= n or another to promote their own cryptographic technology. If a bandwagon= forms of governments, say, using DNSSEC to promote the products of their d= omestic cryptography communities/industries, then DNSSEC users--that is, pr= etty much the entire world user community--will be greatly inconvenienced, = as they repeatedly scramble to update their software to support the new alg= orithms. 2) Encumbered algorithms: A particularly worrisome scenario would be the = adoption by the administrator of a large, important zone of an IPR-encumber= ed algorithm, thus effectively giving the IPR owner (presumably allied with= the zone administrator) the power to control code on the host of every sin= gle client on the planet that needs to securely locate a host in that zone. There may be more dangers I haven't thought of, but these two alone, I thin= k, suffice to make it worthwhile for the WG to attempt to define some forma= l policies regarding new algorithms in DNSSEC, before charging ahead and ad= ding them. =20 Just my 2c, Dan Simon Microsoft Corp. -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Andrew Sullivan Sent: Monday, April 13, 2009 1:06 PM To: namedroppers@ops.ietf.org Subject: Request for adoption (was: [dnsext] New draft has been posted) Dear colleagues, This is a request that WG members to express their opinion as to whether draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG item. We have already had two expressions to the mailing list explicitly expressing support for the adoption of the document. Remember that we must have the commitment of at least five (5) people willing to adopt the document, and to review it. In practice, it is better to have more than five people, since we require at least five supportive reviews in order to send the document on to the IESG. If we can't get five people to say something is a good idea, it is probably not a candidate for IETF standardization. Best regards, Andrew (for the Chairs) On Tue, Apr 07, 2009 at 01:45:28PM +0400, Basil Dolmatov wrote: > Hello! > > Proposed draft for update DNSSec protocol in order to > support GOST cryptographic algorithms in it has been posted to I-D =20 > repository. [&c.] --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to 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 Apr 14 12:08:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859B93A6A8B; Tue, 14 Apr 2009 12:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 V5TABJR2sweC; Tue, 14 Apr 2009 12:08:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90A4E3A659C; Tue, 14 Apr 2009 12:08:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtnvV-0004jX-QW for namedroppers-data0@psg.com; Tue, 14 Apr 2009 19:04:09 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtnvH-0004hw-Os for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 19:04:02 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3EJ3ree040419 for ; Tue, 14 Apr 2009 15:03:53 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904141903.n3EJ3ree040419@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Apr 2009 11:31:22 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) In-Reply-To: <20090413200602.GC24286@shinkuro.com> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 16:06 13/04/2009, Andrew Sullivan wrote: >Dear colleagues, > >This is a request that WG members to express their opinion as to whether >draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG >item. > >We have already had two expressions to the mailing list explicitly >expressing support for the adoption of the document. This document as it stands is performing two actions: adding a new public key algorithm signing algorithm adding a new DS digest type. The threshold for taking these two actions is quite different: the first one has a medium threshold while the second one has a high threshold. Because the document is adding a new DS digest algorithm, I oppose the adoption of the document. Each time a new PK/digest algorithm is added there is a cost to everyone as implementations need to be updated. Once the IANA registry entry is made, there is a lag before the algorithm is widely available in implementations, followed by a deployment lag. During this time a prudent organization that has deployed DNSSEC but one that wants to migrate to the new algorithm is "required" to sign their zone with two algorithms. (right now there is no reliable mechanism to discover the deployment of new algorithm support, but there is an expired ID for an EDNS0 option that can express algorithm support). If a zone goes exclusively with a new algorithm before the algorithm is generally supported it (and potentially its children) will be seen as unsigned. Each time a new DS digest algorithm is added zones are forced to have a DS record for digest algorithm per key. Depending on how DS records are submitted to a parent the parent may not have the ability to calculate the DS record with the new digest. The early years of DNSSEC deployment were dominated to a large extent by political considerations to a great decrement to the actual protocol work. When DNSSEC work was started oppressive export regimes controlled use and distribution of cryptography, and on top of that there were IP issues surrounding the use of the preferred algorithm (RSA). During IESG review of the draft leading to adoption of RFC2065 the IESG mandated that a second algorithm be added: DSA. This happened after the RSA IP holder had provided a non-discriminatory non-fee usage license for the algorithm, and the RSA patent was expiring in less than 2 years. From these experiences I have a real bitter taste of government involvement and dealing with IPR FUD. The last thing I want to see is that DNSSEC PK algorithms become "vanity" algorithms because if we open that door we will see more than just one. From interoperabilty standpoint it is better to have fewer algorithms. The PK algorithm proposed is an elliptic curve algorithm, the WG needs to think about adding ECC PK algorithms. I would love to see how this algorithm stacks up against other suggested ECC algorithms: p256, p384 and Curve25519. We also need to know that implementations are available from multiple sources with licenses that major vendors can use, for example NLnetLabs and Microsoft have different policies on what they can use in their DNSSEC implementations. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 14 12:12:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9F73A69AD; Tue, 14 Apr 2009 12:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=-0.340, 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 EtGmFHQXR279; Tue, 14 Apr 2009 12:12:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 532AA3A6931; Tue, 14 Apr 2009 12:12:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lto0t-000545-QH for namedroppers-data0@psg.com; Tue, 14 Apr 2009 19:09:43 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lto0h-00053D-29 for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 19:09:37 +0000 Received: from [10.31.200.240] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3EJ9Poj040454; Tue, 14 Apr 2009 15:09:25 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Tue, 14 Apr 2009 15:09:17 -0400 To: Dan Simon From: Edward Lewis Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Cc: Andrew Sullivan , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Not a WG criteria but my thoughts... The chief goal of the IETF process is to document approaches to achieving interoperability. If someone wants to create a vanity algorithm for DNSSEC and there's wide-enough appeal to assign a number to the algorithm, then it is in everyone's interests to know what the algorithm number maps to - whether or not they have the software to make use of the knowledge. The discouragement regarding the proliferation of vanity algorithms is that it is not economically sensible to generate your own algorithm and control it. If you go to the expense to develop an algorithm and no one else adopts it into operational practice, you lose your investment. Signing with your own algorithm benefits no one if no one can evaluate the signature, and validating your own algorithm is no good if there are no one generating signatures in it. In some of the early discussions I heard about GOST my point was that economic interests trump both technology and politics. I am not saying the GOST is a political ploy, what I am saying is that defining it for DNSSEC does not set a precedent for algorithms that might be. (Far be it for me to be able to judge if a cryptographic algorithm was politically motivated.) Encumbered algorithms aren't a threat either. If they are so encumbered that the validators can't run them for free, then no one will sign. If signers have to pay, they will seek lower (0) cost alternatives and only offer them. I think the confusion is sometimes over "registering a number", "mandatory to implement" and "mandatory to use." I never advocate for a standard to be "mandatory to use". To me "mandatory to implement" is okay if by that you mean "if you are compliant with RFC WXYZ" which defines the mechanism. "Registering a number" isn't much of a hurdle or stage to me. (We can always expand a number space if we *must*.) At 11:29 -0700 4/14/09, Dan Simon wrote: >Does the WG have any formal statement of criteria by which it will >judge this and future proposals to add algorithms to the DNSSEC >standard? If not, then perhaps it should. I'm concerned in >particular about two dangers: > >1) The proliferation of "vanity algorithms": Because DNSSEC is >expected to become an extremely widely used standard, it's also an >ideal conduit for entities (national governments or even >enterprises) that wish for one reason or another to promote their >own cryptographic technology. If a bandwagon forms of governments, >say, using DNSSEC to promote the products of their domestic >cryptography communities/industries, then DNSSEC users--that is, >pretty much the entire world user community--will be greatly >inconvenienced, as they repeatedly scramble to update their software >to support the new algorithms. > >2) Encumbered algorithms: A particularly worrisome scenario would >be the adoption by the administrator of a large, important zone of >an IPR-encumbered algorithm, thus effectively giving the IPR owner >(presumably allied with the zone administrator) the power to control >code on the host of every single client on the planet that needs to >securely locate a host in that zone. > >There may be more dangers I haven't thought of, but these two alone, >I think, suffice to make it worthwhile for the WG to attempt to >define some formal policies regarding new algorithms in DNSSEC, >before charging ahead and adding them. > > Just my 2c, > > Dan Simon > Microsoft Corp. > > >-----Original Message----- >From: owner-namedroppers@ops.ietf.org >[mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Andrew Sullivan >Sent: Monday, April 13, 2009 1:06 PM >To: namedroppers@ops.ietf.org >Subject: Request for adoption (was: [dnsext] New draft has been posted) > >Dear colleagues, > >This is a request that WG members to express their opinion as to whether >draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG >item. > >We have already had two expressions to the mailing list explicitly >expressing support for the adoption of the document. > >Remember that we must have the commitment of at least five (5) people >willing to adopt the document, and to review it. In practice, it is >better to have more than five people, since we require at least five >supportive reviews in order to send the document on to the IESG. If >we can't get five people to say something is a good idea, it is >probably not a candidate for IETF standardization. > >Best regards, > >Andrew (for the Chairs) > >On Tue, Apr 07, 2009 at 01:45:28PM +0400, Basil Dolmatov wrote: >> Hello! >> >> Proposed draft for update DNSSec protocol in order to >> support GOST cryptographic algorithms in it has been posted to I-D >> repository. > >[&c.] > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 14 12:33:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453EE3A6E16; Tue, 14 Apr 2009 12:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.756 X-Spam-Level: X-Spam-Status: No, score=-0.756 tagged_above=-999 required=5 tests=[AWL=-1.506, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 n7aYbSQvXoa0; Tue, 14 Apr 2009 12:33:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33F3E3A6EC8; Tue, 14 Apr 2009 12:33:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtoKq-0006ao-9r for namedroppers-data0@psg.com; Tue, 14 Apr 2009 19:30:20 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtoKW-0006Z1-Nj for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 19:30:13 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1LtoKU-0002x5-6P for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 21:29:58 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1LtoKT-0005r7-P2 for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 21:29:57 +0200 From: Florian Weimer To: namedroppers@ops.ietf.org Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request References: <20090413200002.GB24286@shinkuro.com> Date: Tue, 14 Apr 2009 21:29:57 +0200 In-Reply-To: <20090413200002.GB24286@shinkuro.com> (Andrew Sullivan's message of "Mon, 13 Apr 2009 16:00:02 -0400") Message-ID: <873acb6nka.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: > E. Description of the proposed RR type. > > Here is the format of the proposed RR type: > > _Service._Proto.Name TTL Class TLSFP Port Mandatory PubKeyAlgo HashAlgo FingerPrint > > Service > The symbolic name of the desired service as defined in > [RFC2782]. > > Proto > The symbolic name of the desired protocol as defined in > [RFC2782]. What are the Service and Proto values when I enter a name in the URL bar of a browser? What values should be used by a GIT/Mercurial/Subversion client? (I'm just curious, this is not within the scope of the RRTYPE request.) > PubKeyAlgo > The algorithm of the public key. This is 8 bit unsigned > number. > > HashAlgo > > The algorithm used to calculate fingerprint hash. This is > 8 bit unsigned number. > > FingerPrint > The fingerprint of the public key. > DNS Security Registry Algorithm Numbers for PubKeyAlgo > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml > Digest Algorithms Registry for HashAlgo > http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml I'm not sure if those are a good match in general. Even today, TLS supports both OpenPGP RSA keys and X.509 certificates involving RSA signatures, and you have to employ some heuristic to tell the two apart. So the *Algo fields suggest a level of protocol flexibility that has to be implemented by other means anyway. I think from a crypto POV, it might make sense for a *TLS*FP record to specify a minimum acceptable version of TLS (to get rid of those pesky downgrade attacks reliably). The relevant TLS crypto algorithms should specify a format for their fingerprints, which should be encoded in a single octet string in the record (whether in text form or binary, I'm not sure). However, the proposal as-is is better than nothing. -- to unsubscribe send a message to namedroppers-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 Apr 14 13:54:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050C83A67F1; Tue, 14 Apr 2009 13:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.73 X-Spam-Level: X-Spam-Status: No, score=-4.73 tagged_above=-999 required=5 tests=[AWL=-1.480, 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 PmAo6Cite6Eu; Tue, 14 Apr 2009 13:54:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16B863A659C; Tue, 14 Apr 2009 13:54:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtpZI-000Bzd-Vf for namedroppers-data0@psg.com; Tue, 14 Apr 2009 20:49:20 +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 1LtpZ6-000Byz-Fp for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 20:49:14 +0000 Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1LtpYy-00007l-DS; Tue, 14 Apr 2009 22:49:05 +0200 Received: from localhost by x27.adm.denic.de with local id 1LtpVm-0005ta-KI; Tue, 14 Apr 2009 22:45:42 +0200 Date: Tue, 14 Apr 2009 22:45:42 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) Message-ID: <20090414204542.GM28795@x27.adm.denic.de> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090413200602.GC24286@shinkuro.com> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Apr 13, 2009 at 04:06:02PM -0400, Andrew Sullivan wrote: > This is a request that WG members to express their opinion as to whether > draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG > item. while formally correct, I believe the question is too narrow. The problem is that all the registries affected by the draft have an assignment policy of "Standards Track", which either means WG adoption or the AD sponsored approach. I do not feel qualified to judge the cryptographic properties of the algorithms involved and I'd like to understand well better than I do currently the layer 9 issues behind the proposal. Maybe the authors could help by explaining some of the operational considerations for "algorithm competition" (where we've been using "algorithm agility" for renewal and increasing resilience, so far). In the end, we can't prevent a Babylonian variety of DNSSEC algorithms by just not looking at the proposal. That said, the draft mixes protocol (implementation) and operational considerations and those should be separated IMHO. -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 Apr 14 14:06:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EFD63A659C; Tue, 14 Apr 2009 14:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.882, 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 wHkqZVl78rTJ; Tue, 14 Apr 2009 14:06:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79C553A67A8; Tue, 14 Apr 2009 14:06:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ltpn4-000D4G-MT for namedroppers-data0@psg.com; Tue, 14 Apr 2009 21:03:34 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ltpml-000D1s-N5 for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 21:03:28 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3EL3AWJ041636; Tue, 14 Apr 2009 17:03:11 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904142103.n3EL3AWJ041636@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 14 Apr 2009 17:02:41 -0400 To: Florian Weimer , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request In-Reply-To: <873acb6nka.fsf@mid.deneb.enyo.de> References: <20090413200002.GB24286@shinkuro.com> <873acb6nka.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 15:29 14/04/2009, Florian Weimer wrote: > > DNS Security Registry Algorithm Numbers for PubKeyAlgo > > > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml > > Digest Algorithms Registry for HashAlgo > > http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml > >I'm not sure if those are a good match in general. Even today, TLS >supports both OpenPGP RSA keys and X.509 certificates involving RSA >signatures, and you have to employ some heuristic to tell the two >apart. So the *Algo fields suggest a level of protocol flexibility >that has to be implemented by other means anyway. Good point I think that TLS ClientCertificateType Identifiers Registry at http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml is more appropriate. along with: TLS HashAlgorithm Registry. Reusing DNSKEY or DS registries will cause problems. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 14 14:14:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD49428C143; Tue, 14 Apr 2009 14:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 vX6YkTDiBUgi; Tue, 14 Apr 2009 14:14:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3DF273A6920; Tue, 14 Apr 2009 14:14:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtpuX-000Da6-2b for namedroppers-data0@psg.com; Tue, 14 Apr 2009 21:11:17 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtpuG-000DYW-SL for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 21:11:10 +0000 Received: from tk5-expfs-c107.redmond.corp.microsoft.com (157.54.69.47) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 14 Apr 2009 14:11:00 -0700 Received: from NA-EXMSG-C115.redmond.corp.microsoft.com ([157.54.61.161]) by tk5-expfs-c107.redmond.corp.microsoft.com ([157.54.69.47]) with mapi; Tue, 14 Apr 2009 14:10:59 -0700 From: Dan Simon To: Edward Lewis CC: Andrew Sullivan , "namedroppers@ops.ietf.org" Date: Tue, 14 Apr 2009 14:10:57 -0700 Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Thread-Topic: Request for adoption (was: [dnsext] New draft has been posted) Thread-Index: Acm9NJSYkapser2XRtebU6JpCBQ8zAACsqHw Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Edward, that's a very reasonable position to take in the context of DNSSEC = as it is today--a little-deployed, little-relied-upon technology. And as l= ong as DNSSEC stays that way, of course, we all have nothing to worry about= . But I assume that most of this WG's participants, at least, expect DNSSEC t= o become a widely-deployed essential component of Internet infrastructure a= t some point in the future. And at that point, the situation changes drast= ically: zone administrators will have a great deal more leverage, because = users will depend on DNSSEC for their applications to work properly and sec= urely. I would like to make sure that by then, the established precedents won't co= me back to haunt everyone. A simple set of declared criteria, established = in advance, could go a long way in that direction. Just my 2c, Dan Simon Microsoft Corp. -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz]=20 Sent: Tuesday, April 14, 2009 12:09 PM To: Dan Simon Cc: Andrew Sullivan; namedroppers@ops.ietf.org Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Not a WG criteria but my thoughts... The chief goal of the IETF process is to document approaches to=20 achieving interoperability. If someone wants to create a vanity=20 algorithm for DNSSEC and there's wide-enough appeal to assign a=20 number to the algorithm, then it is in everyone's interests to know=20 what the algorithm number maps to - whether or not they have the=20 software to make use of the knowledge. The discouragement regarding the proliferation of vanity algorithms=20 is that it is not economically sensible to generate your own=20 algorithm and control it. If you go to the expense to develop an=20 algorithm and no one else adopts it into operational practice, you=20 lose your investment. Signing with your own algorithm benefits no=20 one if no one can evaluate the signature, and validating your own=20 algorithm is no good if there are no one generating signatures in it. In some of the early discussions I heard about GOST my point was that=20 economic interests trump both technology and politics. I am not=20 saying the GOST is a political ploy, what I am saying is that=20 defining it for DNSSEC does not set a precedent for algorithms that=20 might be. (Far be it for me to be able to judge if a cryptographic=20 algorithm was politically motivated.) Encumbered algorithms aren't a threat either. If they are so=20 encumbered that the validators can't run them for free, then no one=20 will sign. If signers have to pay, they will seek lower (0) cost=20 alternatives and only offer them. I think the confusion is sometimes over "registering a number",=20 "mandatory to implement" and "mandatory to use." I never advocate=20 for a standard to be "mandatory to use". To me "mandatory to=20 implement" is okay if by that you mean "if you are compliant with RFC=20 WXYZ" which defines the mechanism. "Registering a number" isn't much=20 of a hurdle or stage to me. (We can always expand a number space if=20 we *must*.) At 11:29 -0700 4/14/09, Dan Simon wrote: >Does the WG have any formal statement of criteria by which it will=20 >judge this and future proposals to add algorithms to the DNSSEC=20 >standard? If not, then perhaps it should. I'm concerned in=20 >particular about two dangers: > >1) The proliferation of "vanity algorithms": Because DNSSEC is=20 >expected to become an extremely widely used standard, it's also an=20 >ideal conduit for entities (national governments or even=20 >enterprises) that wish for one reason or another to promote their=20 >own cryptographic technology. If a bandwagon forms of governments,=20 >say, using DNSSEC to promote the products of their domestic=20 >cryptography communities/industries, then DNSSEC users--that is,=20 >pretty much the entire world user community--will be greatly=20 >inconvenienced, as they repeatedly scramble to update their software=20 >to support the new algorithms. > >2) Encumbered algorithms: A particularly worrisome scenario would=20 >be the adoption by the administrator of a large, important zone of=20 >an IPR-encumbered algorithm, thus effectively giving the IPR owner=20 >(presumably allied with the zone administrator) the power to control=20 >code on the host of every single client on the planet that needs to=20 >securely locate a host in that zone. > >There may be more dangers I haven't thought of, but these two alone,=20 >I think, suffice to make it worthwhile for the WG to attempt to=20 >define some formal policies regarding new algorithms in DNSSEC,=20 >before charging ahead and adding them. > > Just my 2c, > > Dan Simon > Microsoft Corp. > > >-----Original Message----- >From: owner-namedroppers@ops.ietf.org=20 >[mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Andrew Sullivan >Sent: Monday, April 13, 2009 1:06 PM >To: namedroppers@ops.ietf.org >Subject: Request for adoption (was: [dnsext] New draft has been posted) > >Dear colleagues, > >This is a request that WG members to express their opinion as to whether >draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted as a WG >item. > >We have already had two expressions to the mailing list explicitly >expressing support for the adoption of the document. > >Remember that we must have the commitment of at least five (5) people >willing to adopt the document, and to review it. In practice, it is >better to have more than five people, since we require at least five >supportive reviews in order to send the document on to the IESG. If >we can't get five people to say something is a good idea, it is >probably not a candidate for IETF standardization. > >Best regards, > >Andrew (for the Chairs) > >On Tue, Apr 07, 2009 at 01:45:28PM +0400, Basil Dolmatov wrote: >> Hello! >> >> Proposed draft for update DNSSec protocol in order to >> support GOST cryptographic algorithms in it has been posted to I-D >> repository. > >[&c.] > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. > >-- >to 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: --=20 -=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 NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 14 14:35:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9575F3A6B3A; Tue, 14 Apr 2009 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378, 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 qk6w4-Q1mN-6; Tue, 14 Apr 2009 14:34:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFDA23A6E5A; Tue, 14 Apr 2009 14:34:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtqDp-000Eko-Jd for namedroppers-data0@psg.com; Tue, 14 Apr 2009 21:31: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 1LtqDb-000Ek0-O2 for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 21:31:06 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ELUtPB057896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 14:30:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090414204542.GM28795@x27.adm.denic.de> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <20090414204542.GM28795@x27.adm.denic.de> Date: Tue, 14 Apr 2009 14:30:53 -0700 To: Peter Koch , IETF DNSEXT WG From: Paul Hoffman Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:45 PM +0200 4/14/09, Peter Koch wrote: >I do not feel qualified to judge the cryptographic properties >of the algorithms involved That is a reasonable concern. The WG can ask the Crypto Forum Research Group of the IRTF for an opinion. Their charter () says "IETF working groups developing protocols that include cryptographic elements are welcome to bring questions concerning the protocols to CFRG for advice." --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 Apr 14 15:03:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829253A69EB; Tue, 14 Apr 2009 15:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 ec7hZt+WWq2Y; Tue, 14 Apr 2009 15:03:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9693C3A68FE; Tue, 14 Apr 2009 15:03:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ltqf2-000GQ3-G5 for namedroppers-data0@psg.com; Tue, 14 Apr 2009 21:59: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 1Ltqeo-000GPY-H0 for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 21:59:13 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ELx22Q059712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 14:59:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Tue, 14 Apr 2009 14:59:01 -0700 To: Dan Simon , Andrew Sullivan , "namedroppers@ops.ietf.org" From: Paul Hoffman Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:29 AM -0700 4/14/09, Dan Simon wrote: >Does the WG have any formal statement of criteria by which it will judge this and future proposals to add algorithms to the DNSSEC standard? Not that I can see. > If not, then perhaps it should. Doing so has not served other IETF WGs well. > I'm concerned in particular about two dangers: > >1) The proliferation of "vanity algorithms": Because DNSSEC is expected to become an extremely widely used standard, it's also an ideal conduit for entities (national governments or even enterprises) that wish for one reason or another to promote their own cryptographic technology. It is a conduit, but one that comes late in the game. S/MIME, IPsec, and TLS all precede it. > If a bandwagon forms of governments, say, using DNSSEC to promote the products of their domestic cryptography communities/industries, then DNSSEC users--that is, pretty much the entire world user community--will be greatly inconvenienced, as they repeatedly scramble to update their software to support the new algorithms. That has not happened in the case of the three aforementioned WGs. There are plenty of vanity algorithms (to use the derogatory term; I prefer "niche algorithm") that have been standardized in those WGs. The S/MIME WG was, I believe, the first target for GOST. Few of the common clients have support for many of those niche algorithms; the clients in the communities that encompass those niches do. >2) Encumbered algorithms: A particularly worrisome scenario would be the adoption by the administrator of a large, important zone of an IPR-encumbered algorithm, thus effectively giving the IPR owner (presumably allied with the zone administrator) the power to control code on the host of every single client on the planet that needs to securely locate a host in that zone. That makes no sense. A client does not "need" to securely locate a host in that zone. It might really want to, but every implementation decision weighs benefits against costs. IPR encumbrance adds a myriad of costs (money, lawyer time, time spent dealing with IPR zealots of many flavors, and so on). >There may be more dangers I haven't thought of, but these two alone, I think, suffice to make it worthwhile for the WG to attempt to define some formal policies regarding new algorithms in DNSSEC, before charging ahead and adding them. I come to the opposite conclusion: the namespace is nearly free, let people use it as long as their use helps interoperability at least within their niche. --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 Apr 14 15:19:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C16C3A68DA; Tue, 14 Apr 2009 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 kvEJimaFf4m0; Tue, 14 Apr 2009 15:19:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 264BD3A68A8; Tue, 14 Apr 2009 15:19:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtqvW-000HEI-DD for namedroppers-data0@psg.com; Tue, 14 Apr 2009 22:16:22 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtqvJ-000HDQ-MI for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 22:16:15 +0000 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 14 Apr 2009 15:16:09 -0700 Received: from NA-EXMSG-C115.redmond.corp.microsoft.com ([157.54.61.161]) by TK5-EXHUB-C101.redmond.corp.microsoft.com ([157.54.18.48]) with mapi; Tue, 14 Apr 2009 15:15:57 -0700 From: Dan Simon To: Paul Hoffman , Andrew Sullivan , "namedroppers@ops.ietf.org" Date: Tue, 14 Apr 2009 15:15:56 -0700 Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Thread-Topic: Request for adoption (was: [dnsext] New draft has been posted) Thread-Index: Acm9TEhDi3kFAIHEQ5Ob4B9JV/Iy6QAACcaQ Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, there's a huge difference between offering an algorithm for use in S/= MIME, IPsec or TLS and using it to sign DNSSEC records. In the former case= , any two parties that want to ignore the new algorithm are free to do so--= and as you've noted, that's generally been the response to niche algorithms= . In the case of DNSSEC, though, as long as one party finds itself in a zo= ne whose administrator happens to be fond of the niche algorithm, anyone el= se wishing to locate it securely has to support the niche algorithm. That = makes DNSSEC a much more powerful (and therefore, I fear, even more attract= ive) lever for promoters of niche algorithms. =20 Again, I understand all the economic arguments why users won't demand suppo= rt for a large, motley collection of niche algorithms *today*. But if DNSS= EC becomes as widespread and depended-upon as we all hope, then those econo= mic incentives will shift dramatically, and the DNSSEC lever will become ve= ry powerful. Just my 2c, Dan Simon Microsoft Corp. -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Tuesday, April 14, 2009 2:59 PM To: Dan Simon; Andrew Sullivan; namedroppers@ops.ietf.org Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) At 11:29 AM -0700 4/14/09, Dan Simon wrote: >Does the WG have any formal statement of criteria by which it will judge t= his and future proposals to add algorithms to the DNSSEC standard? Not that I can see. > If not, then perhaps it should. Doing so has not served other IETF WGs well. > I'm concerned in particular about two dangers: > >1) The proliferation of "vanity algorithms": Because DNSSEC is expected = to become an extremely widely used standard, it's also an ideal conduit for= entities (national governments or even enterprises) that wish for one reas= on or another to promote their own cryptographic technology. It is a conduit, but one that comes late in the game. S/MIME, IPsec, and TL= S all precede it. > If a bandwagon forms of governments, say, using DNSSEC to promote the pr= oducts of their domestic cryptography communities/industries, then DNSSEC u= sers--that is, pretty much the entire world user community--will be greatly= inconvenienced, as they repeatedly scramble to update their software to su= pport the new algorithms. That has not happened in the case of the three aforementioned WGs. There ar= e plenty of vanity algorithms (to use the derogatory term; I prefer "niche = algorithm") that have been standardized in those WGs. The S/MIME WG was, I = believe, the first target for GOST. Few of the common clients have support = for many of those niche algorithms; the clients in the communities that enc= ompass those niches do. >2) Encumbered algorithms: A particularly worrisome scenario would be the= adoption by the administrator of a large, important zone of an IPR-encumbe= red algorithm, thus effectively giving the IPR owner (presumably allied wit= h the zone administrator) the power to control code on the host of every si= ngle client on the planet that needs to securely locate a host in that zone= . That makes no sense. A client does not "need" to securely locate a host in = that zone. It might really want to, but every implementation decision weigh= s benefits against costs. IPR encumbrance adds a myriad of costs (money, la= wyer time, time spent dealing with IPR zealots of many flavors, and so on). >There may be more dangers I haven't thought of, but these two alone, I thi= nk, suffice to make it worthwhile for the WG to attempt to define some form= al policies regarding new algorithms in DNSSEC, before charging ahead and a= dding them. I come to the opposite conclusion: the namespace is nearly free, let people= use it as long as their use helps interoperability at least within their n= iche. --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 Apr 14 15:28:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE53A3A68E1; Tue, 14 Apr 2009 15:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[AWL=-1.403, 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 MbbFzfhNwlLu; Tue, 14 Apr 2009 15:28:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DBEA3A67A6; Tue, 14 Apr 2009 15:28:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ltr3u-000Hj5-AP for namedroppers-data0@psg.com; Tue, 14 Apr 2009 22:25:02 +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 1Ltr3h-000HiM-GO for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 22:24:55 +0000 Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1Ltr3g-0001CE-5Q; Wed, 15 Apr 2009 00:24:48 +0200 Received: from localhost by x27.adm.denic.de with local id 1Ltr0U-0006fN-B0; Wed, 15 Apr 2009 00:21:30 +0200 Date: Wed, 15 Apr 2009 00:21:30 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request Message-ID: <20090414222130.GC24323@x27.adm.denic.de> References: <20090413200002.GB24286@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090413200002.GB24286@shinkuro.com> User-Agent: Mutt/1.4.2.3i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Apr 13, 2009 at 04:00:02PM -0400, Andrew Sullivan wrote: > I hereby post the attached template for public review, under the terms > of RFC 5395. This posting begins the formal comment period under > section 3.1.1 (1) in RFC 5395. the idea looks interesting and worth pursuing. However, I do not believe the proposal qualifies for the simple Expert Review assignment of section 3.1.1. More formally, the RR type assignment could be done this way, but the proposed application of that RR type in an SRV like fashion deserves more thought and consideration. > D. Motivation for the new RRTYPE application? > > There is a need to publish a public key information in DNS, which > would provide sufficient trust to allow an authentication of a > server side public key. There is a need to indicate that a secure > connection to a service is mandatory. Data included in this new > RRTYPE together with the DNSSEC will create a secure chain leading > to establishing a secured connection from a client (such as a web > browser) to a server. New RRTYPE will include a flag to indicate This is a dangerous misconception. RRSIGs are for origin authentication only, they do not qualify as certificates for any key material that they happen to sign outside of DNSSEC itself. The chain has a gap. > that a secure connection to a specified service is required. Note > this new RRTYPE is a generic to all protocols and services. > > E. Description of the proposed RR type. > > Here is the format of the proposed RR type: > > _Service._Proto.Name TTL Class TLSFP Port Mandatory PubKeyAlgo HashAlgo FingerPrint > > Service > The symbolic name of the desired service as defined in > [RFC2782]. > > Proto > The symbolic name of the desired protocol as defined in > [RFC2782]. Given the far less than optimal experience with RFC 2782 and applicability statements more guidance is needed here. What is the querying sequence and what does the presence or absence of a TLSFP RR indicate? Does it parallel an SRV or is it supposed to act as a replacement? Which protocols are supposed to use it in the first place? Is the key associated with the service or with the (server) entity delivering the service? I'd like to encourage the proposer to describe the framework and its interaction with SRV as well as application scenarios in more detail in an Internet-Draft. The "light" process is inappropriate IMHO. -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 Apr 14 15:39:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9753B3A6B8F; Tue, 14 Apr 2009 15:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 1oX6NKHevOky; Tue, 14 Apr 2009 15:39:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A53273A6820; Tue, 14 Apr 2009 15:39:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtrEQ-000Ije-U7 for namedroppers-data0@psg.com; Tue, 14 Apr 2009 22:35:54 +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 1LtrED-000Iip-DH for namedroppers@ops.ietf.org; Tue, 14 Apr 2009 22:35:48 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EMZbCr061649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 15:35:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Tue, 14 Apr 2009 15:35:36 -0700 To: Dan Simon , Andrew Sullivan , "namedroppers@ops.ietf.org" From: Paul Hoffman Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 3:15 PM -0700 4/14/09, Dan Simon wrote: >Paul, there's a huge difference between offering an algorithm for use in S/MIME, IPsec or TLS and using it to sign DNSSEC records. In the former case, any two parties that want to ignore the new algorithm are free to do so--and as you've noted, that's generally been the response to niche algorithms. That's not completely true. A party who is identified by a trust anchor that uses a niche algorithm can only be verified by other parties who also know that algorithm. This is closer to... > In the case of DNSSEC, though, as long as one party finds itself in a zone whose administrator happens to be fond of the niche algorithm, anyone else wishing to locate it securely has to support the niche algorithm. That's partially true. A better statement would be "In the case of DNSSEC, though, as long as one party has chosen its name to be in a zone whose administrator only signs the zone with the niche algorithm, anyone else wishing to locate it securely has to support the niche algorithm." If you need to control a zone that needs to be validated by many people, you will either pressure your superior zone to make that possible or pick a different superior zone. > That makes DNSSEC a much more powerful (and therefore, I fear, even more attractive) lever for promoters of niche algorithms. There is no stronger promotional mechanism that national laws. >Again, I understand all the economic arguments why users won't demand support for a large, motley collection of niche algorithms *today*. But if DNSSEC becomes as widespread and depended-upon as we all hope, then those economic incentives will shift dramatically, and the DNSSEC lever will become very powerful. We thought that about S/MIME, IPsec, and TLS. Only the latter has proven worth notice. Even with that, your company's web browser does not support all the niche algorithms that have been defined for TLS, much less for S/MIME and IPsec. --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 Apr 15 00:41:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1123A6A21; Wed, 15 Apr 2009 00:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 05To5uceJkHA; Wed, 15 Apr 2009 00:41:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E0233A6B98; Wed, 15 Apr 2009 00:40:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtzcO-000NCD-DH for namedroppers-data0@psg.com; Wed, 15 Apr 2009 07:33:12 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtzcC-000NBM-52 for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 07:33:06 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Ltzc3-00012P-Rd; Wed, 15 Apr 2009 09:32:51 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Ltzc3-0002np-5f; Wed, 15 Apr 2009 09:32:51 +0200 From: Florian Weimer To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request References: <20090413200002.GB24286@shinkuro.com> <873acb6nka.fsf@mid.deneb.enyo.de> <200904142103.n3EL3AWJ041636@stora.ogud.com> Date: Wed, 15 Apr 2009 09:32:51 +0200 In-Reply-To: <200904142103.n3EL3AWJ041636@stora.ogud.com> (Olafur Gudmundsson's message of "Tue, 14 Apr 2009 17:02:41 -0400") Message-ID: <8763h6l6cc.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: * Olafur Gudmundsson: > At 15:29 14/04/2009, Florian Weimer wrote: > >> > DNS Security Registry Algorithm Numbers for PubKeyAlgo >> > >> http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml >> > Digest Algorithms Registry for HashAlgo >> > http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml >> >>I'm not sure if those are a good match in general. Even today, TLS >>supports both OpenPGP RSA keys and X.509 certificates involving RSA >>signatures, and you have to employ some heuristic to tell the two >>apart. So the *Algo fields suggest a level of protocol flexibility >>that has to be implemented by other means anyway. > > > > Good point I think that > TLS ClientCertificateType Identifiers Registry at > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > is more appropriate. Hmm. Maybe I'm confused, but those don't seem to cover OpenPGP, either. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 15 01:19:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376C53A6AE5; Wed, 15 Apr 2009 01:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.737 X-Spam-Level: X-Spam-Status: No, score=0.737 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 1a1fr-Xc-9nd; Wed, 15 Apr 2009 01:19:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 103E03A6403; Wed, 15 Apr 2009 01:19:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu0H5-0000Jv-QK for namedroppers-data0@psg.com; Wed, 15 Apr 2009 08:15:15 +0000 Received: from [209.85.220.162] (helo=mail-fx0-f162.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu0Gr-0000IW-G8 for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 08:15:08 +0000 Received: by fxm6 with SMTP id 6so2971262fxm.41 for ; Wed, 15 Apr 2009 01:14:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.116.72 with SMTP id l8mr2445221faq.33.1239783299305; Wed, 15 Apr 2009 01:14:59 -0700 (PDT) In-Reply-To: <873acb6nka.fsf@mid.deneb.enyo.de> References: <20090413200002.GB24286@shinkuro.com> <873acb6nka.fsf@mid.deneb.enyo.de> Date: Wed, 15 Apr 2009 10:14:59 +0200 Message-ID: Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Florian Weimer Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Apr 14, 2009 at 9:29 PM, Florian Weimer wrote: >> =C2=A0 =C2=A0E. =C2=A0 =C2=A0Description of the proposed RR type. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here is the format of the proposed RR = type: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_Service._Proto.Name TTL Class TLSFP P= ort Mandatory PubKeyAlgo HashAlgo FingerPrint >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Service >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The symbolic nam= e of the desired service as defined in >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC2782]. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Proto >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The symbolic nam= e of the desired protocol as defined in >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC2782]. > > What are the Service and Proto values when I enter a name in the URL > bar of a browser? _http._tcp > What values should be used by a GIT/Mercurial/Subversion client? _svn._tcp (if the service is svn and not ssh) > (I'm just curious, this is not within the scope of the RRTYPE request.) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PubKeyAlgo >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The algorithm of= the public key. =C2=A0This is 8 bit unsigned >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HashAlgo >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The algorithm us= ed to calculate fingerprint hash. =C2=A0This is >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8 bit unsigned n= umber. >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FingerPrint >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The fingerprint = of the public key. > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DNS Security Registry Algorithm Number= s for PubKeyAlgo >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.iana.org/assignment= s/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Digest Algorithms Registry for HashAlg= o >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.iana.org/assignment= s/ds-rr-types/ds-rr-types.xhtml > > I'm not sure if those are a good match in general. =C2=A0Even today, TLS > supports both OpenPGP RSA keys and X.509 certificates involving RSA > signatures, and you have to employ some heuristic to tell the two > apart. =C2=A0So the *Algo fields suggest a level of protocol flexibility > that has to be implemented by other means anyway. Just to clarify, are you speaking about 5081? So I know where to look. > I think from a crypto POV, it might make sense for a *TLS*FP record to > specify a minimum acceptable version of TLS (to get rid of those pesky > downgrade attacks reliably). Are you sure that people will be able to distinguish between TLS 1.0, 1.1 and 1.2? > The relevant TLS crypto algorithms should specify a format for their > fingerprints, which should be encoded in a single octet string in > the record (whether in text form or binary, I'm not sure). Isn't that outside of scope of this request (and future RFC)? I'm trying to= keep this as simple as possible. Ondrej --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Apr 15 01:42:21 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F47F3A6A99; Wed, 15 Apr 2009 01:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, 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 VS6N18Q8121O; Wed, 15 Apr 2009 01:42:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61A3F3A6A21; Wed, 15 Apr 2009 01:42:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu0d1-0001cE-86 for namedroppers-data0@psg.com; Wed, 15 Apr 2009 08:37:55 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu0cj-0001az-TU for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 08:37:46 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1Lu0cd-000345-T9; Wed, 15 Apr 2009 10:37:32 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1Lu0cd-00038Q-68; Wed, 15 Apr 2009 10:37:31 +0200 From: Florian Weimer To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request References: <20090413200002.GB24286@shinkuro.com> <873acb6nka.fsf@mid.deneb.enyo.de> Date: Wed, 15 Apr 2009 10:37:31 +0200 In-Reply-To: (=?utf-8?Q?=22Ond=C5=99ej_Sur=C3=BD=22's?= message of "Wed, 15 Apr 2009 10:14:59 +0200") Message-ID: <87bpqyjos4.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * Ond=C5=99ej Sur=C3=BD: >> What are the Service and Proto values when I enter a name in the URL >> bar of a browser? > > _http._tcp > >> What values should be used by a GIT/Mercurial/Subversion client? > > _svn._tcp > (if the service is svn and not ssh) So I have to say beforehand which transport protocol I use? Hmm. >> I'm not sure if those are a good match in general. =C2=A0Even today, TLS >> supports both OpenPGP RSA keys and X.509 certificates involving RSA >> signatures, and you have to employ some heuristic to tell the two >> apart. =C2=A0So the *Algo fields suggest a level of protocol flexibility >> that has to be implemented by other means anyway. > > Just to clarify, are you speaking about 5081? So I know where to look. Yes, RFC 5081. >> I think from a crypto POV, it might make sense for a *TLS*FP record to >> specify a minimum acceptable version of TLS (to get rid of those pesky >> downgrade attacks reliably). > > Are you sure that people will be able to distinguish between TLS 1.0, > 1.1 and 1.2? I think you should do the TLSFP lookup, and if there is a minimum version indication, specify that when you initialize the TLS connection. Most TLS APIs seem to include the ability. >> The relevant TLS crypto algorithms should specify a format for their >> fingerprints, which should be encoded in a single octet string in >> the record (whether in text form or binary, I'm not sure). > > Isn't that outside of scope of this request (and future RFC)? I'm trying = to keep > this as simple as possible. It is. The problem is that there is currently no public key fingerprint defined by TLS, so there's more work than just creating the record type. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From marmcn@alston.com Wed Apr 15 06:08:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179DB3A6E60 for ; Wed, 15 Apr 2009 06:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.678 X-Spam-Level: X-Spam-Status: No, score=-35.678 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HELO_EQ_FR=0.35, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 13UCxqPKSelh for ; Wed, 15 Apr 2009 06:07:57 -0700 (PDT) Received: from ip-219.net-80-236-8.asnieres.rev.numericable.fr (ip-219.net-80-236-8.asnieres.rev.numericable.fr [80.236.8.219]) by core3.amsl.com (Postfix) with SMTP id BCBF33A6E5C for ; Wed, 15 Apr 2009 06:07:54 -0700 (PDT) To: Subject: Re: Discount code #26922 From: VIAGRA . Official Site MIME-Version: 1.0 Content-Type: text/html Message-Id: <20090415130754.BCBF33A6E5C@core3.amsl.com> Date: Wed, 15 Apr 2009 06:07:54 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Wed Apr 15 06:37:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084C728C1B0; Wed, 15 Apr 2009 06:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=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 0ojD2yvdbOen; Wed, 15 Apr 2009 06:37:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16C5928C178; Wed, 15 Apr 2009 06:37:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu5CS-000L75-1C for namedroppers-data0@psg.com; Wed, 15 Apr 2009 13:30:48 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu5CF-000L67-1D for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 13:30:41 +0000 Received: from [10.31.200.240] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3FDUTOA048901; Wed, 15 Apr 2009 09:30:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Wed, 15 Apr 2009 09:25:27 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 15:15 -0700 4/14/09, Dan Simon wrote: >In the case of DNSSEC, though, as long as one party finds itself in a zone >whose administrator happens to be fond of the niche algorithm, anyone else >wishing to locate it securely has to support the niche algorithm. That is the same situation as for the other examples cited. Outside of a brief flirtation, I have never used PGP yet can read mail from people that PGP'ify their email. Securely? Well, it hasn't mattered, I've never been in a situation where the "security" of an email message has been an issue. When it comes to mechanisms for digital signature, the receiver can ignore the security cruft and still see the message. The receiver does not have to buy into the security algorithm. Backwards compatibility was one of the features we fought to keep in DNSSEC. Just so "unknown algorithms" could be present and not throw the receiver into SERVFAIL land. DNSSEC is supposed to be a "slap on" addition - not get in the way of existing operations and just add value to those that invest in it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 15 06:54:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B24D3A6E6A; Wed, 15 Apr 2009 06:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.316, 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 WMmz9lqqMltD; Wed, 15 Apr 2009 06:54:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A45383A6C0B; Wed, 15 Apr 2009 06:54:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu5Vx-000MJW-QI for namedroppers-data0@psg.com; Wed, 15 Apr 2009 13:50:57 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu5Vi-000MIC-Mv for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 13:50:51 +0000 Received: from [10.31.200.240] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3FDoa74049029; Wed, 15 Apr 2009 09:50:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090414222130.GC24323@x27.adm.denic.de> References: <20090413200002.GB24286@shinkuro.com> <20090414222130.GC24323@x27.adm.denic.de> Date: Wed, 15 Apr 2009 09:50:33 -0400 To: Peter Koch From: Edward Lewis Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 0:21 +0200 4/15/09, Peter Koch wrote: >This is a dangerous misconception. RRSIGs are for origin authentication only, >they do not qualify as certificates for any key material that they happen >to sign outside of DNSSEC itself. The chain has a gap. Ah - this is the most precise and concise statement of the rationale why the SYKED BoF never got past round 1, why the generic key flag in KEY RR never became an RFC - but also captures why SSHFP and IPSECKEY did. The rationale for SSH and IPSEC is that there is enough "shared fate" between what they are "protecting" and IP address assignment and the placement of address records in DNS. I.e., in a large organization, a SysAdmin will uncrate a computer, load up an OS including a network stack, load a terminal app (SSH) and other stuff and then drop it on the desk of (say) a Web Developer after submitting new data for the DNS (or via DHCP, etc., etc.). The security/trust gap is seen organizationally between the SysAdmin and the Web Developer, for one. Returning to Peter for clarification, is the problem a lack of documentation of "shared fate apps" and no statement restricting the unfettered use of this record within that set of apps? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 15 08:56:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33F13A694A; Wed, 15 Apr 2009 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-1.015, 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 VPbXeEZmEw6x; Wed, 15 Apr 2009 08:56:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D22EF3A6936; Wed, 15 Apr 2009 08:56:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu7PQ-0005XB-8a for namedroppers-data0@psg.com; Wed, 15 Apr 2009 15:52:20 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu7PD-0005WB-J5 for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 15:52:13 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3FFq5TF050259 for ; Wed, 15 Apr 2009 11:52:05 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904151552.n3FFq5TF050259@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Apr 2009 11:51:52 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: [dnsext] WGLC summary: DNS Proxy Implementation Guidelines Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The document had 9 reviewers, some of the reviewers raised minor issues with text or approach. Based on this the document passes WGLC. Changes needed before the document is advanced: Few nits raised that chair and editor have agreed on are non significant or obvious corrections. Change in title to add the word Broadband. Action: Rejected does not add anything and may be used to exempt hot-spot and hotel proxies from the guidelines in the draft. Changes: Add to introduction: State that having access to full resolvers w/o proxy is preferable. Section 4.5 Change SHOULD to MUST Section 5.2: suggestion: change recommendation from "SHOULD NOT" to "MUST NOT" Not sure if this will have adverse effect. Editor has reviewed all earlier comments for compliance with RFC5378, and assured chairs that there are no IPR issues. Editor will issue a new version, one week after that version is announced it will be advanced to the IESG for IETF evaluation. 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 Wed Apr 15 09:00:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4353A69CF; Wed, 15 Apr 2009 09:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.195 X-Spam-Level: X-Spam-Status: No, score=-8.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_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 kiFIkUpd0SJV; Wed, 15 Apr 2009 09:00:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 375953A69E7; Wed, 15 Apr 2009 09:00:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu7P5-0005W0-Ib for namedroppers-data0@psg.com; Wed, 15 Apr 2009 15:51:59 +0000 Received: from [131.107.115.214] (helo=smtp.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu7Os-0005VA-Mi for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 15:51:53 +0000 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 15 Apr 2009 08:51:46 -0700 Received: from NA-EXMSG-C115.redmond.corp.microsoft.com ([157.54.61.161]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.88.96]) with mapi; Wed, 15 Apr 2009 08:51:31 -0700 From: Dan Simon To: Edward Lewis , "namedroppers@ops.ietf.org" Date: Wed, 15 Apr 2009 08:51:31 -0700 Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Thread-Topic: Request for adoption (was: [dnsext] New draft has been posted) Thread-Index: Acm9zvdOsc7VESp1S127bJ+E8FFDuAABml+Q Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Edward, I agree with you completely that in scenarios, such as your PGP exp= erience, where security is a completely unnecessary option, fallback to ins= ecure operation is a perfectly acceptable alternative in the case of algori= thm incompatibility. Of course, if all scenarios were like that, then DNSS= EC would be a complete waste of time and effort that ought to be abandoned = immediately. However, those of us who care about DNSSEC presumably do so because we beli= eve that security in DNS is--or at least will be, in the foreseeable future= --a very important and valuable feature in many scenarios. If we're correc= t about that, then a statement like, "people can always fall back to insecu= re DNS" is not a satisfactory answer to the problem of algorithm incompatib= ility. We want people to be able to rely on secure DNS, not to have to hop= e for the best, design more dependable alternatives, or give up on secure h= ost location altogether. =20 Let's not forget that DNS itself was once young, incomplete and untested en= ough that application writers made sure not to rely on it for important hos= t location tasks. Does that mean that we'd be comfortable with major zones= adopting non-backward-compatible record formats today, since people can al= ways fall back to whatever non-DNS methods they used back then? Just my 2c, Dan Simon Microsoft Corp. =20 -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.o= rg] On Behalf Of Edward Lewis Sent: Wednesday, April 15, 2009 6:25 AM To: namedroppers@ops.ietf.org Cc: ed.lewis@neustar.biz Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) At 15:15 -0700 4/14/09, Dan Simon wrote: >In the case of DNSSEC, though, as long as one party finds itself in a zone >whose administrator happens to be fond of the niche algorithm, anyone else >wishing to locate it securely has to support the niche algorithm. That is the same situation as for the other examples cited. Outside of a brief flirtation, I have never used PGP yet can read=20 mail from people that PGP'ify their email. Securely? Well, it=20 hasn't mattered, I've never been in a situation where the "security"=20 of an email message has been an issue. When it comes to mechanisms for digital signature, the receiver can=20 ignore the security cruft and still see the message. The receiver=20 does not have to buy into the security algorithm. Backwards compatibility was one of the features we fought to keep in=20 DNSSEC. Just so "unknown algorithms" could be present and not throw=20 the receiver into SERVFAIL land. DNSSEC is supposed to be a "slap=20 on" addition - not get in the way of existing operations and just add=20 value to those that invest in it. --=20 -=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 NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to 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 Apr 15 09:51:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9D23A6BE1; Wed, 15 Apr 2009 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.225, 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 kv+p3xEIJMIK; Wed, 15 Apr 2009 09:51:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BB123A6AD0; Wed, 15 Apr 2009 09:50:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu8Fo-0009F4-KM for namedroppers-data0@psg.com; Wed, 15 Apr 2009 16:46:28 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu8Fb-0009Do-Hb for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 16:46:21 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id D16E83A6B43; Wed, 15 Apr 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090415164501.D16E83A6B43@core3.amsl.com> Date: Wed, 15 Apr 2009 09:45: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 Proxy Implementation Guidelines Author(s) : R. Bellis Filename : draft-ietf-dnsext-dnsproxy-04.txt Pages : 13 Date : 2009-04-15 This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-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-dnsproxy-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-15093358.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 Apr 15 11:43:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC2F3A6F2B; Wed, 15 Apr 2009 11:43:41 -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 d2xD3xKxDFPU; Wed, 15 Apr 2009 11:43:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3D9C3A6E1E; Wed, 15 Apr 2009 11:43:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9zr-000Gui-RD for namedroppers-data0@psg.com; Wed, 15 Apr 2009 18:38:07 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lu9ze-000GtR-N0 for namedroppers@ops.ietf.org; Wed, 15 Apr 2009 18:38:01 +0000 Received: from [10.31.200.240] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3FIbnqq052175; Wed, 15 Apr 2009 14:37:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Wed, 15 Apr 2009 14:37:46 -0400 To: "namedroppers@ops.ietf.org" From: Edward Lewis Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 8:51 -0700 4/15/09, Dan Simon wrote: >However, those of us who care about DNSSEC presumably do so because we >believe that security in DNS is--or at least will be, in the foreseeable >future--a very important and valuable feature in many scenarios. The question in front of us now is how to get there. There have been a number of technologies that have died which started out with grand ideas but, at least in part, they were too rigid in their assumptions about the environment they came to an end. I am thinking of Asynchronous Transfer Mode, MacOS before X, DEC, etc. Technologies that molded themselves to the environment have flourished, including MS Windows (yeah), POSIX-like operating systems, IEEE 802, etc. DNS is a great example of something poorly specified succeeding because of it. It's a come-as-you-want-to-be technology. The lack of rigidity in operations meant it has avoided cracking at it's pressured points. As we developed DNSSEC we became more and more in awe of this. At first, we moaned that DNS wasn't tightly defined enough to be secured. But as we struggled with the problem we began to admire how the flexibility had given the DNS life. This is where we are with DNSSEC now. If we take on a rigid stance when it comes to something like the cryptographic algorithms, we will not only crack DNSSEC (such as tempting interests to fragment and sign the root differently or setting up some house-of-cards architectural nightmare where one bump topples the entire structure) we will be running counter to the DNS architectural philosophy. It is one thing to be rigid in architecture and another to be rigid in implementation. I think that should be explained. If the architecture is flexible we can do a lot with it. An architecture should serve the needs without restricting unnecessarily the functions within. Implementations are different - if an implementation is lax in enforcing security (drilling to that because that's the topic), it is hard to harden against newly considered threats because it is hard to enforce field upgrades and patches. I mention this because DNSSEC has a restrictive trust model (the reason trust anchor repositories are always in the mail these days) but should be liberal in cryptographic work. If the WG had cryptographic expertise I would be for restricting algorithms based on their cryptographic chops. Instead, what I look for is interoperability, network-wide adoption and the like. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From larry@alphaomegamex.com Wed Apr 15 13:11:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07CD3A6C53 for ; Wed, 15 Apr 2009 13:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.18 X-Spam-Level: X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 YWFAW-SOgz7R for ; Wed, 15 Apr 2009 13:11:06 -0700 (PDT) Received: from adsl-dyn144.78-98-177.t-com.sk (adsl-dyn144.78-98-177.t-com.sk [78.98.177.144]) by core3.amsl.com (Postfix) with SMTP id C5FEB3A6C44 for ; Wed, 15 Apr 2009 13:10:44 -0700 (PDT) To: " Date: Wed, 15 Apr 2009 13:10:44 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@lists.ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From krispyfried@abspc.com Wed Apr 15 17:02:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E833A6A7D for ; Wed, 15 Apr 2009 17:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.651 X-Spam-Level: X-Spam-Status: No, score=-10.651 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 f8SofmwS-z5N for ; Wed, 15 Apr 2009 17:02:19 -0700 (PDT) Received: from adsl-dyn85.78-99-43.t-com.sk (adsl-dyn85.78-99-43.t-com.sk [78.99.43.85]) by core3.amsl.com (Postfix) with SMTP id 7AFD63A6A2A for ; Wed, 15 Apr 2009 17:02:09 -0700 (PDT) To: " Date: Wed, 15 Apr 2009 17:02:09 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Thu Apr 16 01:49:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB283A688B; Thu, 16 Apr 2009 01:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 7Z-D42Ae04mo; Thu, 16 Apr 2009 01:49:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E3B13A6359; Thu, 16 Apr 2009 01:49:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNAc-000GZW-6N for namedroppers-data0@psg.com; Thu, 16 Apr 2009 08:42:06 +0000 Received: from [209.85.218.161] (helo=mail-bw0-f161.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNAQ-000GYM-9Y for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 08:42:00 +0000 Received: by bwz5 with SMTP id 5so288037bwz.41 for ; Thu, 16 Apr 2009 01:41:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.118.141 with SMTP id v13mr316222faq.26.1239871311935; Thu, 16 Apr 2009 01:41:51 -0700 (PDT) In-Reply-To: References: <20090413200002.GB24286@shinkuro.com> Date: Thu, 16 Apr 2009 10:41:51 +0200 Message-ID: Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Paul Hoffman Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Apr 13, 2009 at 11:04 PM, Paul Hoffman wrot= e: > This application is OK as it stands. I propose some changes that the prop= oser may or may not like. None of the proposed changes would cause the prop= osal to be rejected, but changing them now would mean that a later revision= would not be needed. > > a) The name should be something other than "TLSFP" because the RRTYPE def= inition is not limited to TLS. Something like "PKFP" better matches the des= cription. I was trying to make something more focused like SSLFP is. Hence limiting this to TLS protocol. > b) The description should at least mention the fact that the public key l= isted in the RRTYPE might not be the public key used by the responder at Se= rvice.Proto.Port.Name. That is, even if a signed record says that the publi= c key for _pop._tcp.110.popserver.example.com is KeyA, that server might st= ill offer KeyB in a certificate that the user would trust based on a differ= ent trust chain than the DNSSEC trust chain. This is quite an important dis= tinction; without it, this RRTYPE description hints that *only* the named k= ey that will be found at the given location. True, I'll include this in draft. Thanks for remarks. Ondrej. --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Apr 16 01:53:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634713A688B; Thu, 16 Apr 2009 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 HT4uNn6kKEsW; Thu, 16 Apr 2009 01:53:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 530583A6845; Thu, 16 Apr 2009 01:53:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNHL-000H7w-D7 for namedroppers-data0@psg.com; Thu, 16 Apr 2009 08:49:03 +0000 Received: from [209.85.218.161] (helo=mail-bw0-f161.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNH8-000H6y-VE for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 08:48:57 +0000 Received: by bwz5 with SMTP id 5so291269bwz.41 for ; Thu, 16 Apr 2009 01:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.107.19 with SMTP id z19mr334969fao.27.1239871728891; Thu, 16 Apr 2009 01:48:48 -0700 (PDT) In-Reply-To: <20090414222130.GC24323@x27.adm.denic.de> References: <20090413200002.GB24286@shinkuro.com> <20090414222130.GC24323@x27.adm.denic.de> Date: Thu, 16 Apr 2009 10:48:48 +0200 Message-ID: Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Peter Koch Cc: IETF DNSEXT WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >> =C2=A0 =C2=A0D. =C2=A0 =C2=A0Motivation for the new RRTYPE application? >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There is a need to publish a public ke= y information in DNS, which >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would provide sufficient trust to allo= w an authentication of a >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server side public key. =C2=A0There is= a need to indicate that a secure >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection to a service is mandatory. = =C2=A0Data included in this new >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RRTYPE together with the DNSSEC will c= reate a secure chain leading >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to establishing a secured connection f= rom a client (such as a web >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0browser) to a server. =C2=A0New RRTYPE= will include a flag to indicate > > This is a dangerous misconception. RRSIGs are for origin authentication o= nly, > they do not qualify as certificates for any key material that they happen > to sign outside of DNSSEC itself. =C2=A0The chain has a gap. Could you please elaborate more? I am quite unsure what you have on your mind here. What's the difference between this and SSHFP? Both are just indications that secure communication should(must) be established with certain public key on server side. > I'd like to encourage the proposer to describe the framework and its > interaction with SRV as well as application scenarios in more detail in > an Internet-Draft. =C2=A0The "light" process is inappropriate IMHO. OK, I'll finish that I-D I started to write anyway. Ondrej --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Apr 16 01:58:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4991C3A6B1E; Thu, 16 Apr 2009 01:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.773 X-Spam-Level: X-Spam-Status: No, score=0.773 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 V3nG1Gtsbcme; Thu, 16 Apr 2009 01:58:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FC133A680A; Thu, 16 Apr 2009 01:58:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNLz-000HRV-D1 for namedroppers-data0@psg.com; Thu, 16 Apr 2009 08:53:51 +0000 Received: from [209.85.220.162] (helo=mail-fx0-f162.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNLf-000HPV-5D for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 08:53:44 +0000 Received: by fxm6 with SMTP id 6so299575fxm.41 for ; Thu, 16 Apr 2009 01:53:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.75 with SMTP id e11mr331748fap.51.1239872009957; Thu, 16 Apr 2009 01:53:29 -0700 (PDT) In-Reply-To: <87bpqyjos4.fsf@mid.deneb.enyo.de> References: <20090413200002.GB24286@shinkuro.com> <873acb6nka.fsf@mid.deneb.enyo.de> <87bpqyjos4.fsf@mid.deneb.enyo.de> Date: Thu, 16 Apr 2009 10:53:29 +0200 Message-ID: Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Florian Weimer Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Apr 15, 2009 at 10:37 AM, Florian Weimer wrote: > * Ond=C5=99ej Sur=C3=BD: > >>> What are the Service and Proto values when I enter a name in the URL >>> bar of a browser? >> >> _http._tcp >> >>> What values should be used by a GIT/Mercurial/Subversion client? >> >> _svn._tcp >> (if the service is svn and not ssh) > > So I have to say beforehand which transport protocol I use? =C2=A0Hmm. Is that a problem? Could you please provide a case which would cause troubles with this approach? >>> I'm not sure if those are a good match in general. =C2=A0Even today, TL= S >>> supports both OpenPGP RSA keys and X.509 certificates involving RSA >>> signatures, and you have to employ some heuristic to tell the two >>> apart. =C2=A0So the *Algo fields suggest a level of protocol flexibilit= y >>> that has to be implemented by other means anyway. >> >> Just to clarify, are you speaking about 5081? So I know where to look. > > Yes, RFC 5081. But isn't that generic and it's http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml which needs fixing? >>> I think from a crypto POV, it might make sense for a *TLS*FP record to >>> specify a minimum acceptable version of TLS (to get rid of those pesky >>> downgrade attacks reliably). >> >> Are you sure that people will be able to distinguish between TLS 1.0, >> 1.1 and 1.2? > > I think you should do the TLSFP lookup, and if there is a minimum > version indication, specify that when you initialize the TLS > connection. =C2=A0Most TLS APIs seem to include the ability. I understand your point, I'll look on that. It could be specified as option= al parameter. I am afraid though that more we complicate this then less people will be able to use it. >>> The relevant TLS crypto algorithms should specify a format for their >>> fingerprints, which should be encoded in a single octet string in >>> the record (whether in text form or binary, I'm not sure). >> >> Isn't that outside of scope of this request (and future RFC)? I'm trying= to keep >> this as simple as possible. > > It is. =C2=A0The problem is that there is currently no public key > fingerprint defined by TLS, so there's more work than just creating > the record type. Looks like cross-wg work to me. Argh. :) Ondrej --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Apr 16 02:19:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDA93A6B3D; Thu, 16 Apr 2009 02:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.084 X-Spam-Level: * X-Spam-Status: No, score=1.084 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, 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 6ubk6GDjZiDg; Thu, 16 Apr 2009 02:19:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8EFD28C1CF; Thu, 16 Apr 2009 02:19:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNhJ-000J2u-Vo for namedroppers-data0@psg.com; Thu, 16 Apr 2009 09:15:53 +0000 Received: from [209.85.218.161] (helo=mail-bw0-f161.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuNh6-000J0p-Fq for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 09:15:47 +0000 Received: by bwz5 with SMTP id 5so303004bwz.41 for ; Thu, 16 Apr 2009 02:15:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.106.14 with SMTP id v14mr337519fao.49.1239873338364; Thu, 16 Apr 2009 02:15:38 -0700 (PDT) In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Date: Thu, 16 Apr 2009 11:15:38 +0200 Message-ID: Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Dan Simon Cc: Edward Lewis , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dan, On Wed, Apr 15, 2009 at 5:51 PM, Dan Simon wrote: > Edward, I agree with you completely that in scenarios, such as your PGP e= xperience, where security is a completely unnecessary option, fallback to i= nsecure operation is a perfectly acceptable alternative in the case of algo= rithm incompatibility. =C2=A0Of course, if all scenarios were like that, th= en DNSSEC would be a complete waste of time and effort that ought to be aba= ndoned immediately. I really don't see difference between DNSSEC and PGP (or S/MIME). DNSSEC is not something which should be mandatory for every zone in the DNS and it should never become so. > However, those of us who care about DNSSEC presumably do so because we be= lieve that security in DNS is--or at least will be, in the foreseeable futu= re--a very important and valuable feature in many scenarios. =C2=A0If we're= correct about that, then a statement like, "people can always fall back to= insecure DNS" is not a satisfactory answer to the problem of algorithm inc= ompatibility. =C2=A0We want people to be able to rely on secure DNS, not to= have to hope for the best, design more dependable alternatives, or give up= on secure host location altogether. Those of us who care about DNSSEC will use well-supported algorithm. Rest of the world will not use DNSSEC at all anyway - and why should they? Is there a value of signing all my domain names I have? Nope. I will sign only zones which hold something important (like my blog :-P). Also if I understand it, there are places in the world where RSA(DSA) is not acceptable (by law) and for those people we need to provide flexibility. I am not big supporter of entirely free market and I think some regulations are required for the sake of people, but right here right now I would take more laissez-faire approach. > Let's not forget that DNS itself was once young, incomplete and untested = enough that application writers made sure not to rely on it for important h= ost location tasks. =C2=A0Does that mean that we'd be comfortable with majo= r zones adopting non-backward-compatible record formats today, since people= can always fall back to whatever non-DNS methods they used back then? > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just my 2c, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dan Simon > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Microsoft Corp. > > > -----Original Message----- > From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf= .org] On Behalf Of Edward Lewis > Sent: Wednesday, April 15, 2009 6:25 AM > To: namedroppers@ops.ietf.org > Cc: ed.lewis@neustar.biz > Subject: RE: Request for adoption (was: [dnsext] New draft has been poste= d) > > At 15:15 -0700 4/14/09, Dan Simon wrote: >>In the case of DNSSEC, though, as long as one party finds itself in a zon= e >>whose administrator happens to be fond of the niche algorithm, anyone els= e >>wishing to locate it securely has to support the niche algorithm. > > That is the same situation as for the other examples cited. > > Outside of a brief flirtation, I have never used PGP yet can read > mail from people that PGP'ify their email. =C2=A0Securely? =C2=A0Well, it > hasn't mattered, I've never been in a situation where the "security" > of an email message has been an issue. > > When it comes to mechanisms for digital signature, the receiver can > ignore the security cruft and still see the message. =C2=A0The receiver > does not have to buy into the security algorithm. > > Backwards compatibility was one of the features we fought to keep in > DNSSEC. =C2=A0Just so "unknown algorithms" could be present and not throw > the receiver into SERVFAIL land. =C2=A0DNSSEC is supposed to be a "slap > on" addition - not get in the way of existing operations and just add > value to those that invest in it. > -- > -=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 > NeuStar =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0You can leave a voice message at +1-571-434-5468 > > Getting everything you want is easy if you don't want much. > > -- > to 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: > --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Apr 16 03:02:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF2C3A6AE0; Thu, 16 Apr 2009 03:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.394 X-Spam-Level: ** X-Spam-Status: No, score=2.394 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, 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 MZUl13nntp3h; Thu, 16 Apr 2009 03:02:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 76E6D28C242; Thu, 16 Apr 2009 03:01:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuOL5-000LvN-JZ for namedroppers-data0@psg.com; Thu, 16 Apr 2009 09:56:59 +0000 Received: from [209.86.89.66] (helo=elasmtp-spurfowl.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuOKr-000LuI-VC for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 09:56:52 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=qqThu4b8yHPwRR+cuDHCfpDfZJZeWOgxfCTWqaU9Y3j/0TBSwgkU+SboaG6Uwzlo; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.98.82] (helo=ix.netcom.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LuOJZ-0007UC-NK; Thu, 16 Apr 2009 05:55:27 -0400 Message-ID: <49E70058.75AA073B@ix.netcom.com> Date: Thu, 16 Apr 2009 02:54:32 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ond?ej =?iso-8859-1?Q?Sur=FD?= CC: Dan Simon , "namedroppers@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688de4257b58790a3eecdb2e2e39eb7577b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.98.82 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ondrej and all, I hope you will change your mind on this. DNSSEC is unfortunately necessary as miscreants of various sorts are picking the DNS to pieces at the expense of the market place to which you so well and so strongly support. I hope as a responsible person, that you want all users to have a safe and secure Internet experience, and DNSSEC is one step in moving in that positive direction. I am also sure that your government also feels likewise as it positively benefits the vast majority of Check citizens by improving the safety and security of electronic trade opertunities with my country and others accordingly. I am sure you nor your government wants to put at further risk IP sensitive goods as well, and DNSSEC plays a role in reducing that risk. Ond?ej Surý wrote: > Dan, > > On Wed, Apr 15, 2009 at 5:51 PM, Dan Simon wrote: > > Edward, I agree with you completely that in scenarios, such as your PGP experience, where security is a completely unnecessary option, fallback to insecure operation is a perfectly acceptable alternative in the case of algorithm incompatibility.  Of course, if all scenarios were like that, then DNSSEC would be a complete waste of time and effort that ought to be abandoned immediately. > > I really don't see difference between DNSSEC and PGP (or S/MIME). > DNSSEC is not something which should be mandatory for every zone in > the DNS and it should never become so. > > > However, those of us who care about DNSSEC presumably do so because we believe that security in DNS is--or at least will be, in the foreseeable future--a very important and valuable feature in many scenarios.  If we're correct about that, then a statement like, "people can always fall back to insecure DNS" is not a satisfactory answer to the problem of algorithm incompatibility.  We want people to be able to rely on secure DNS, not to have to hope for the best, design more dependable alternatives, or give up on secure host location altogether. > > Those of us who care about DNSSEC will use well-supported algorithm. > Rest of the world will not use DNSSEC at all anyway - and why should > they? > > Is there a value of signing all my domain names I have? Nope. I will > sign only zones which hold something important (like my blog :-P). > > Also if I understand it, there are places in the world where RSA(DSA) > is not acceptable (by law) and for those people we need to provide > flexibility. I am not big supporter of entirely free market and I > think some regulations are required for the sake of people, but right > here right now I would take more laissez-faire approach. > > > Let's not forget that DNS itself was once young, incomplete and untested enough that application writers made sure not to rely on it for important host location tasks.  Does that mean that we'd be comfortable with major zones adopting non-backward-compatible record formats today, since people can always fall back to whatever non-DNS methods they used back then? > > > >                 Just my 2c, > > > >                 Dan Simon > >                 Microsoft Corp. > > > > > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Edward Lewis > > Sent: Wednesday, April 15, 2009 6:25 AM > > To: namedroppers@ops.ietf.org > > Cc: ed.lewis@neustar.biz > > Subject: RE: Request for adoption (was: [dnsext] New draft has been posted) > > > > At 15:15 -0700 4/14/09, Dan Simon wrote: > >>In the case of DNSSEC, though, as long as one party finds itself in a zone > >>whose administrator happens to be fond of the niche algorithm, anyone else > >>wishing to locate it securely has to support the niche algorithm. > > > > That is the same situation as for the other examples cited. > > > > Outside of a brief flirtation, I have never used PGP yet can read > > mail from people that PGP'ify their email.  Securely?  Well, it > > hasn't mattered, I've never been in a situation where the "security" > > of an email message has been an issue. > > > > When it comes to mechanisms for digital signature, the receiver can > > ignore the security cruft and still see the message.  The receiver > > does not have to buy into the security algorithm. > > > > Backwards compatibility was one of the features we fought to keep in > > DNSSEC.  Just so "unknown algorithms" could be present and not throw > > the receiver into SERVFAIL land.  DNSSEC is supposed to be a "slap > > on" addition - not get in the way of existing operations and just add > > value to those that invest in it. > > -- > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Edward Lewis > > NeuStar           You can leave a voice message at +1-571-434-5468 > > > > Getting everything you want is easy if you don't want much. > > > > -- > > to 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: > > > > -- > Ondrej Sury > technicky reditel/Chief Technical Officer > ----------------------------------------- > CZ.NIC, z.s.p.o. -- .cz domain registry > Americka 23,120 00 Praha 2,Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > sip:ondrej.sury@nic.cz tel:+420.222745110 > mob:+420.739013699 fax:+420.222745112 > ----------------------------------------- > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-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 Apr 16 03:28:23 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4BD3A6CAC; Thu, 16 Apr 2009 03:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 HIpxyL5D9eOI; Thu, 16 Apr 2009 03:28:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08AC73A6A6E; Thu, 16 Apr 2009 03:28:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuOm6-000Nwk-6W for namedroppers-data0@psg.com; Thu, 16 Apr 2009 10:24:54 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuOlt-000Nvu-Aw for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 10:24:47 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 4C35E327A87; Thu, 16 Apr 2009 10:24:40 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id 0F550327A85; Thu, 16 Apr 2009 10:24:38 +0000 (UTC) Message-ID: <49E70766.3030602@isc.org> Date: Thu, 16 Apr 2009 05:24:38 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Jeffrey A. Williams" CC: =?ISO-8859-1?Q?Ond=3Fej_Sur=FD?= , Dan Simon , "namedroppers@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Subject: [dnsext] Re: Request for adoption References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> In-Reply-To: <49E70058.75AA073B@ix.netcom.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeffrey A. Williams wrote: > Ondrej and all, > > I hope you will change your mind on this. DNSSEC is unfortunately > necessary as miscreants of various sorts are picking the DNS to pieces > at the expense of the market place to which you so well and so strongly > support. I hope as a responsible person, that you want all users > to have a safe and secure Internet experience, and DNSSEC is one > step in moving in that positive direction. I know I'm going to get flamed for this... - From my point of view, I know DNSSEC is happening, and it fixes many DNS problems (cache attacks, the infamous ID guessing attacks). However, I tend to feel that an increase in transaction security would have also fixed many of these attacks. DNSSEC seems, in many ways, to be a very complicated and somewhat fragile(*) solution that took 10 years to find a problem. We are, in deploying DNSSEC, requiring that every resolver that wants to be secured, track a root key. Forever. Securely. And all the software has to be changed to check signatures, or otherwise be DNSSEC aware. Since many bits of software are changing, why not just make the ID field be 128 bits long? EDNS provides the perfect method to do this, and the change is far less drastic than DNSSEC. It would cause little to no operational impact (other than changing resolvers of course). I know this is a rather simplistic view on things, but sometimes I wonder if we aren't pushing DNSSEC as hard as we can for reasons that no one but those pushing so hard can justify. (*) Fragile, in this case: Zones are no longer one-time configure and leave them for years. They have expiration dates. So much new code is coming into play, and the failure modes are far more and far harder to explain to users. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknnB2YACgkQLdqv0r6eD6YChgCdGuMCAB7MlfJI9qh5AGa4Ij2J SUAAn1eTWXvrEkiPoNoFiMoubdMLM9zU =HAeg -----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 Thu Apr 16 04:18:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BE73A69FE; Thu, 16 Apr 2009 04:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6, 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 D95VKAlbOUgb; Thu, 16 Apr 2009 04:18:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3D043A680A; Thu, 16 Apr 2009 04:18:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuPXu-0001ew-UB for namedroppers-data0@psg.com; Thu, 16 Apr 2009 11:14:18 +0000 Received: from [209.85.218.161] (helo=mail-bw0-f161.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuPXf-0001dN-Ft for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 11:14:12 +0000 Received: by bwz5 with SMTP id 5so361837bwz.41 for ; Thu, 16 Apr 2009 04:14:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.103.194 with SMTP id l2mr366792fao.55.1239880441315; Thu, 16 Apr 2009 04:14:01 -0700 (PDT) In-Reply-To: <49E70766.3030602@isc.org> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> Date: Thu, 16 Apr 2009 13:14:01 +0200 Message-ID: Subject: [dnsext] Re: Request for adoption From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Michael Graff Cc: "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Since many bits of software are changing, why not just make the ID field > be 128 bits long? =C2=A0EDNS provides the perfect method to do this, and = the > change is far less drastic than DNSSEC. =C2=A0It would cause little to no > operational impact (other than changing resolvers of course). You cannot do that without backwards compatibility. And if you keep backwar= ds compatibility you are prone to downgrade attacks, ie.: Case 1: edns1_client: 128bit ID query edns1_server: EDNS1+128bit ID response vs. Case 2: edns1_client: 128bit ID query edns0_server: normal ID response vs. Case 3: edns1_client: 128bit ID query attacker: normal ID response (edns1_server: 128bit ID response) How do you differentiate Case 2 and Case 3 (without some sort of handshake)= ? Ondrej --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Apr 16 04:31:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0344F3A6B6E; Thu, 16 Apr 2009 04:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.287 X-Spam-Level: X-Spam-Status: No, score=-4.287 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 GBU+oZplp3oZ; Thu, 16 Apr 2009 04:31:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28D6E3A6ABF; Thu, 16 Apr 2009 04:30:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuPlB-0002dl-Gl for namedroppers-data0@psg.com; Thu, 16 Apr 2009 11:28:01 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuPkz-0002cg-7W for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 11:27:55 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id 7E880327A87; Thu, 16 Apr 2009 11:27:48 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id AA96A327A85; Thu, 16 Apr 2009 11:27:47 +0000 (UTC) Message-ID: <49E71633.7080901@isc.org> Date: Thu, 16 Apr 2009 06:27:47 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: "namedroppers@ops.ietf.org" Subject: [dnsext] Re: Request for adoption References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OndÅ™ej Surý wrote: > How do you differentiate Case 2 and Case 3 (without some sort of handshake)? Why not have a handshake? I know DNS is stateless, and needs to remain so. We're already multiplying traffic by something obscene in using DNSSEC, it would hardly be wrong to either add such a handshake, or retransmit more than once with a 128-bit keyid, and each retransmission using a different 16-bit query ID, and compare the results. Sure, that will break load balancers which return fast changing information, but from what I remember DNSSEC already does that too. I'm not anti-DNSSEC, btw. I think it is what will happen, if only that it has a lot of effort behind it. I'm just not certain it is the right solution to the problems people seem to hope it to fix, and the problems it causes and the price people pay to use it are not insignificant. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknnFjIACgkQLdqv0r6eD6br4wCZAVVBr2Q/kEHvUhtUr9sROQmj sGAAn2whxF5/hdvUtLC3i7F+BZ21hye5 =o0mF -----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 Thu Apr 16 06:08:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71473A6D37; Thu, 16 Apr 2009 06:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 5blLeBf06vRi; Thu, 16 Apr 2009 06:08:35 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 0B9F13A6CCD; Thu, 16 Apr 2009 06:08:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuRIH-000Alg-BO for namedroppers-data0@psg.com; Thu, 16 Apr 2009 13:06:17 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuRI3-000Ak5-6N for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 13:06:11 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3GD5u3m021801; Thu, 16 Apr 2009 06:05:56 -0700 (PDT) Cc: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Michael Graff , "namedroppers@ops.ietf.org" Message-Id: <26073257-DA29-489B-8715-D1F05FCFCE34@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Nicholas Weaver In-Reply-To: <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Date: Thu, 16 Apr 2009 06:05:56 -0700 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: OOPs: minor corrections... Non-upgraded authorities see TRIPLE the load. And yes, I was previously down on double-sided changes outside of DNSSEC in the past. I've changed my mind, as a result of Ondrej Sury's question, which made me realize we can handle the "downgrade" attack and maintain compatibility. -- to unsubscribe send a message to namedroppers-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 Apr 16 06:08:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408663A6CCD; Thu, 16 Apr 2009 06:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 PzeGHQsnC9MC; Thu, 16 Apr 2009 06:08:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BA263A6D0D; Thu, 16 Apr 2009 06:08:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuREb-000ARD-Ql for namedroppers-data0@psg.com; Thu, 16 Apr 2009 13:02:29 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuREO-000AQD-0T for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 13:02:21 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3GD1upj021477; Thu, 16 Apr 2009 06:01:57 -0700 (PDT) Cc: Nicholas Weaver , Michael Graff , "namedroppers@ops.ietf.org" Message-Id: <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> From: Nicholas Weaver To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Date: Thu, 16 Apr 2009 06:01:56 -0700 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 16, 2009, at 4:14 AM, Ond=C5=99ej Sur=C3=BD wrote: >> Since many bits of software are changing, why not just make the ID =20= >> field >> be 128 bits long? EDNS provides the perfect method to do this, and =20= >> the >> change is far less drastic than DNSSEC. It would cause little to no >> operational impact (other than changing resolvers of course). > > You cannot do that without backwards compatibility. And if you keep =20= > backwards > compatibility you are prone to downgrade attacks, ie.: Actually, you are NOT prone to downgrade attacks. Here's why: In order to construct a downgrade attack, the attacker needs to be in =20= path. And as I repeatedly rant, I dont' care about in-path attackers (except =20= for the ISP's own recursive resolver) when securing DNS, because DNS =20 isn't the end protocol, and if the end-protocol is vulnerable to an in-=20= path attacker, its dead anyway regardless of DNSSEC, and if the end-=20 protocol is immune to an in-path attacker, it never really trusted the =20= DNS name. And frankly, we can use the marketplace and incentives to solve the =20 out of path attacker by the EDNS extended query ID mechanisms: edns-ping_resolver: 128bit ID query If the authority (or attacker) doesn't include the extended query ID =20 in response: a) Do two more queries, if the results are identical, accept it. If =20= the second or third reply includes the correct extended query ID, =20 accept that. (Handles the attacker case). b) If the name is NOT stable, do a TCP connection to the server for =20 the query. c) If it refuses TCP, accept one of the three results but DO NOT =20 CACHE THE RESULT. Thus you have effectively full backwards compatibility, AND protection =20= from downgrade attacks: For stable names: If the server is not upgraded to do the 128b edns reply, it just sees =20= at most double the load. Attacker can't do a downgrade attack, as he needs to with 3 races in a =20= row. For unstable names: If the server is not upgraded to do the 128b edns reply: If the name =20= is made slightly stable (2-3 queries from the same resolver in a =20 couple of seconds sees the same result), it just sees at most double =20 the load. Attacker can't do a downgrade attack. If the server is not upgraded and the name is unstable: It sees a =20 large TCP load. Attacker can't do a downgrade. If the server is not upgraded, the name is unstable, and it refuses =20 TCP: It sees a huge increase in requests as they are not cached. =20 Attacker is limited to blind transaction attacks rather than blind =20 cache attacks (FAR less powerful an attack). But you notice: it still all works, and now there is a nice incentive =20= not to screw up, and an attacker can't just ignore the EDNS bit in its =20= reply, because you still have the legitimate server, and the attacker =20= would have to win THREE races in a row. Thus: a) THe attacker has to guess a 128b EDNS query ID, for all cases =20 except unstable, non-TCP supporting names a') Even against unstable, non-TCP supporting names, the attacker is =20= now limited to blind transaction attacks. b) DNS still works, with good protection, for stable names without it =20= (3x queries with 0x20 -> >60b of entropy), c) DNS still works, for unstable names without it. d) Partial deployment WORKS!, as authorities will slowly see their =20 load increase as resolvers are updated, if the authorities don't change. So although an EDNS ping is a "double sided" change, its an actually =20 deployable double-sided change. -- to unsubscribe send a message to namedroppers-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 Apr 16 06:48:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31943A6B6E; Thu, 16 Apr 2009 06:48: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 I-ig-eteOO0j; Thu, 16 Apr 2009 06:48:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4B373A6D6A; Thu, 16 Apr 2009 06:48:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuRsi-000E0O-Cy for namedroppers-data0@psg.com; Thu, 16 Apr 2009 13:43:56 +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 1LuRsN-000Dyj-I0 for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 13:43:49 +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.3/8.14.3) with ESMTP id n3GDhOqb090740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 15:43:25 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <49E735FC.5060000@nlnetlabs.nl> Date: Thu, 16 Apr 2009 15:43:24 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Nicholas Weaver CC: "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <26073257-DA29-489B-8715-D1F05FCFCE34@ICSI.Berkeley.EDU> In-Reply-To: <26073257-DA29-489B-8715-D1F05FCFCE34@ICSI.Berkeley.EDU> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 16 Apr 2009 15:43:25 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nicholas, Thank you for this very good EDNS ping story. The EDNS ping draft should be saying this sort of thing. Your work completes the draft nicely. The actions look reasonable to me; but you forget to factor in that if the three outstanding queries are done at the same time, some sort of birthday paradox would happen (since fake packets can match 3 queries at the same time). Nicholas Weaver wrote: > OOPs: minor corrections... > > Non-upgraded authorities see TRIPLE the load. Well, how about my forgery-resistance draft; it also has the same work - about triple the load, but only requires resolver deployment. I think it worth protecting the in-path too. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknnNfwACgkQkDLqNwOhpPgJ4wCeNob/3zWwJ3vu6s97VdGHdDut LfMAn3D04heR8nd7sNFZIXIpkghMi/kM =stO8 -----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 Thu Apr 16 06:59:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16E23A6D5F; Thu, 16 Apr 2009 06:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, J_CHICKENPOX_32=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 aX4A4sscDX-s; Thu, 16 Apr 2009 06:59:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B42793A6F48; Thu, 16 Apr 2009 06:59:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuS3W-000EvA-7u for namedroppers-data0@psg.com; Thu, 16 Apr 2009 13:55:06 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuS3H-000Ety-8u for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 13:54:58 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 28EA4A103E; Thu, 16 Apr 2009 13:54:45 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Michael Graff cc: "Jeffrey A. Williams" , =?us-ascii?Q?=3D=3FISO-8859-1=3FQ=3FOnd=3D3Fej=5FSur=3DFD=3F=3D?= , Dan Simon , "namedroppers\@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Subject: Re: [dnsext] Re: Request for adoption In-Reply-To: Your message of "Thu\, 16 Apr 2009 05\:24\:38 EST." <49E70766.3030602@isc.org> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 13:54:45 +0000 Message-ID: <65829.1239890085@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: michael, no flame intended here. path security helps against various kinds of problems but does nothing for "provider in the middle" attacks where a hotel middlebox, or a load balancer, or an nxdomain remapper, can break the "domain owner's intent : rrset content" mapping. this, combined with the comparatively minor problem of kaminsky-style poisoning or other off-path attacks, means that there is no reason for confidence in dns's results, which discourages the development of a whole class of applications. (and as kaminsky has showed, it also fails to discourage a whole class of applications who show designed-in misplaced confidence in the answers they get from dns.) i've been flogging dnssec all these years not because of problems that a larger TID or universal deployment of BCP38 would have solved, but because i want to enable to creation of new dnssec-aware applications which behave differently in the presence of signed data. there is no way to justify dnssec's costs (to date or as projected) on the basis of kaminsky alone. --paul re: > Date: Thu, 16 Apr 2009 05:24:38 -0500 > From: Michael Graff > User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) > To: "Jeffrey A. Williams" > CC: Ond?ej Sur=FD ,=20 > Dan Simon , > "namedroppers@ops.ietf.org" ,=20 > doc/ntia DNSSEC , > USTR General contact > Subject: [dnsext] Re: Request for adoption > Sender: owner-namedroppers@ops.ietf.org >=20 > Jeffrey A. Williams wrote: > > Ondrej and all, > >=20 > > I hope you will change your mind on this. DNSSEC is unfortunately > > necessary as miscreants of various sorts are picking the DNS to pieces > > at the expense of the market place to which you so well and so strongly > > support. I hope as a responsible person, that you want all users > > to have a safe and secure Internet experience, and DNSSEC is one > > step in moving in that positive direction. >=20 > I know I'm going to get flamed for this... >=20 > From my point of view, I know DNSSEC is happening, and it fixes many DNS > problems (cache attacks, the infamous ID guessing attacks). However, I > tend to feel that an increase in transaction security would have also > fixed many of these attacks. DNSSEC seems, in many ways, to be a very > complicated and somewhat fragile(*) solution that took 10 years to find > a problem. >=20 > We are, in deploying DNSSEC, requiring that every resolver that wants to > be secured, track a root key. Forever. Securely. And all the software > has to be changed to check signatures, or otherwise be DNSSEC aware. >=20 > Since many bits of software are changing, why not just make the ID field > be 128 bits long? EDNS provides the perfect method to do this, and the > change is far less drastic than DNSSEC. It would cause little to no > operational impact (other than changing resolvers of course). >=20 > I know this is a rather simplistic view on things, but sometimes I > wonder if we aren't pushing DNSSEC as hard as we can for reasons that no > one but those pushing so hard can justify. >=20 > (*) Fragile, in this case: Zones are no longer one-time configure and > leave them for years. They have expiration dates. So much new code is > coming into play, and the failure modes are far more and far harder to > explain to users. >=20 > --Michael >=20 > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-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 Apr 16 07:19:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D96D3A6D74; Thu, 16 Apr 2009 07:19:49 -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.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_17=0.6, J_CHICKENPOX_23=0.6, 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 Rso9+x30NjEw; Thu, 16 Apr 2009 07:19:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E734A3A6F28; Thu, 16 Apr 2009 07:19:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuSMV-000Gbi-H1 for namedroppers-data0@psg.com; Thu, 16 Apr 2009 14:14:43 +0000 Received: from [209.85.218.161] (helo=mail-bw0-f161.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuSMH-000Gap-JH for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 14:14:35 +0000 Received: by bwz5 with SMTP id 5so469618bwz.41 for ; Thu, 16 Apr 2009 07:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.55.200 with SMTP id v8mr1322342bkg.54.1239891267642; Thu, 16 Apr 2009 07:14:27 -0700 (PDT) In-Reply-To: <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> Date: Thu, 16 Apr 2009 16:14:27 +0200 Message-ID: Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= To: Nicholas Weaver Cc: Michael Graff , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 16, 2009 at 3:01 PM, Nicholas Weaver wrote: > > On Apr 16, 2009, at 4:14 AM, Ond=C5=99ej Sur=C3=BD wrote: > >>> Since many bits of software are changing, why not just make the ID fiel= d >>> be 128 bits long? =C2=A0EDNS provides the perfect method to do this, an= d the >>> change is far less drastic than DNSSEC. =C2=A0It would cause little to = no >>> operational impact (other than changing resolvers of course). >> >> You cannot do that without backwards compatibility. And if you keep >> backwards >> compatibility you are prone to downgrade attacks, ie.: > > Actually, you are NOT prone to downgrade attacks. True, if you deploy more forgery resistance techniques like n*queries (whic= h could be deployed without 128bit ID/EDNS ping). Simple 128bit ID won't help here. But thanks for clarification. Ondrej --=20 Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -- to unsubscribe send a message to namedroppers-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 Apr 16 07:50:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBB53A6F6A; Thu, 16 Apr 2009 07:50:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char DE hex): To: Ond\336ej Sur\230 ) id 1LuSrs-000JTP-8j for namedroppers-data0@psg.com; Thu, 16 Apr 2009 14:47:08 +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 1LuSrc-000JRf-P2 for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 14:47:00 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEkkDU030262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 07:46:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20090413200002.GB24286@shinkuro.com> Date: Thu, 16 Apr 2009 07:46:46 -0700 To: OndÞej Sur˜ From: Paul Hoffman Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 10:41 AM +0200 4/16/09, OndÞej Sur˜ wrote: >On Mon, Apr 13, 2009 at 11:04 PM, Paul Hoffman wrote: >> This application is OK as it stands. I propose some changes that the proposer may or may not like. None of the proposed changes would cause the proposal to be rejected, but changing them now would mean that a later revision would not be needed. >> >> a) The name should be something other than "TLSFP" because the RRTYPE definition is not limited to TLS. Something like "PKFP" better matches the description. > >I was trying to make something more focused like SSLFP is. Hence >limiting this to TLS protocol. I do not see where in your application it says that the key is only to be used in TLS. This is a pretty large omission. If you mean it to only be for TLS, then you need to describe the TLS modes in which it can (and cannot) be used. I'm glad that you have said that you will now do this as a draft; it really could use input from the TLS WG. --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 Apr 16 08:39:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3D328C233; Thu, 16 Apr 2009 08:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.289, 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 AMFFM+PbnODc; Thu, 16 Apr 2009 08:38:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C06F93A6F74; Thu, 16 Apr 2009 08:38:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuTbZ-000NZ3-AO for namedroppers-data0@psg.com; Thu, 16 Apr 2009 15:34:21 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuTbL-000NXj-TZ for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 15:34:14 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 80FD7A1017 for ; Thu, 16 Apr 2009 15:34:07 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: Your message of "Thu, 16 Apr 2009 16:14:27 +0200." References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 16 Apr 2009 15:34:07 +0000 Message-ID: <70202.1239896047@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > >> You cannot do that without backwards compatibility. And if you keep > >> backwards compatibility you are prone to downgrade attacks, ie.: > > > > Actually, you are NOT prone to downgrade attacks. > > True, if you deploy more forgery resistance techniques like n*queries > (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID > won't help here. But thanks for clarification. adding more queries brings all kinds of questions of its own like which one to use if the answers aren't all the same. also, punishing folks who don't upgrade by increasing their load. (dns-0x20 does this also, but the size of the punished population is smaller, being limited only to folks who downcase or upcase QNAMEs in their responses, which was never prohibited or required.) i think that any effort beyond dns-0x20 to secure against off-path attackers is misplaced. dns must be secured end to end, which will not only enable a new class of dnssec-aware applications, but obviate the need to secure dns hop by hop. -- to unsubscribe send a message to namedroppers-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 Apr 16 09:44:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9B73A6D02; Thu, 16 Apr 2009 09:44:34 -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 RZB5IMAaENmo; Thu, 16 Apr 2009 09:44:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C76513A69E6; Thu, 16 Apr 2009 09:44:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuUeu-0002yS-AZ for namedroppers-data0@psg.com; Thu, 16 Apr 2009 16:41:52 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuUeg-0002x0-Iu for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 16:41:45 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 96BBCA1018; Thu, 16 Apr 2009 16:41:37 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Michael Graff cc: "Jeffrey A. Williams" , =?ISO-8859-1?Q?Ond=3Fej_Sur=FD?= , Dan Simon , "namedroppers@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Subject: Re: [dnsext] Re: Request for adoption In-Reply-To: Your message of "Thu, 16 Apr 2009 11:37:50 EST." <49E75EDE.7050909@isc.org> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <65829.1239890085@nsa.vix.com> <49E75EDE.7050909@isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 16 Apr 2009 16:41:37 +0000 Message-ID: <73412.1239900097@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ..., it is too bad that we didn't fix the underlying cause of a > lot of the, the ID being too short. i think the lack of BCP38 deployment is the prime underlying cause of far more badness than anything having to do with the size of the TID. -- to unsubscribe send a message to namedroppers-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 Apr 16 09:44:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEE23A6D02; Thu, 16 Apr 2009 09:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.407 X-Spam-Level: X-Spam-Status: No, score=-4.407 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 q-snp5cO5PSp; Thu, 16 Apr 2009 09:44:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C358D3A69E6; Thu, 16 Apr 2009 09:44:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuUbO-0002br-OQ for namedroppers-data0@psg.com; Thu, 16 Apr 2009 16:38:14 +0000 Received: from [204.152.186.144] (helo=white.flame.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuUb4-0002Zz-78 for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 16:38:07 +0000 Received: from white.flame.org (localhost [127.0.0.1]) by white.flame.org (Postfix) with ESMTP id ECF9A327A87; Thu, 16 Apr 2009 16:37:51 +0000 (UTC) Received: from bigmac.home.flame.org (unknown [149.20.65.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by white.flame.org (Postfix) with ESMTP id D66B0327A85; Thu, 16 Apr 2009 16:37:50 +0000 (UTC) Message-ID: <49E75EDE.7050909@isc.org> Date: Thu, 16 Apr 2009 11:37:50 -0500 From: Michael Graff User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Paul Vixie CC: "Jeffrey A. Williams" , =?ISO-8859-1?Q?Ond=3Fej_Sur=FD?= , Dan Simon , "namedroppers@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Subject: Re: [dnsext] Re: Request for adoption References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <65829.1239890085@nsa.vix.com> In-Reply-To: <65829.1239890085@nsa.vix.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=BE9E0FA6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Vixie wrote: > michael, no flame intended here. path security helps against various kinds > of problems but does nothing for "provider in the middle" attacks where a > hotel middlebox, or a load balancer, or an nxdomain remapper, can break the > "domain owner's intent : rrset content" mapping. Count my ranting up to a sleep-deprived brain working to hard on a particular problem last night. I clearly wasn't able to say what I meant. What I was TRYING to get at is that while we're all here changing all this stuff, it is too bad that we didn't fix the underlying cause of a lot of the, the ID being too short. Clearly I need to block port 25 on my firewall and use enabling it as a consciousness test. - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknnXt0ACgkQLdqv0r6eD6ZZ4gCfdsG2yLKJPKjssKrCKVHCXpKS AvQAoIxI3F5MbVW9V1J2OUN6cdkti85v =cq9K -----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 Thu Apr 16 10:50:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D463A6BC6; Thu, 16 Apr 2009 10:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.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 hpkscHBKv-aJ; Thu, 16 Apr 2009 10:50:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B8873A6BBA; Thu, 16 Apr 2009 10:50:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuVdJ-0008bm-A6 for namedroppers-data0@psg.com; Thu, 16 Apr 2009 17:44:17 +0000 Received: from [64.18.2.217] (helo=exprod7og115.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuVd5-0008Zy-Uk for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 17:44:10 +0000 Received: from source ([64.89.228.229]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSeduXZ91fcmx6Ph+J4tuVakgwWDVg8in@postini.com; Thu, 16 Apr 2009 10:44:03 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B92891B83EB; Thu, 16 Apr 2009 10:44:09 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 16 Apr 2009 10:43:56 -0700 CC: "Jeffrey A. Williams" , =?ISO-8859-1?Q?Ond=3Fej_Sur=FD?= , Dan Simon , "namedroppers@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Message-ID: <57A269A8-F8A8-4E6B-AD35-AC1408CE19B3@nominum.com> From: Ted Lemon To: Michael Graff In-Reply-To: <49E70766.3030602@isc.org> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Re: Request for adoption Date: Thu, 16 Apr 2009 10:43:55 -0700 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 16, 2009, at 3:24 AM, Michael Graff wrote: > We are, in deploying DNSSEC, requiring that every resolver that > wants to > be secured, track a root key. Forever. Securely. And all the > software > has to be changed to check signatures, or otherwise be DNSSEC aware. The current state of the art is that DNS is not secure: it's quite common to encounter access provider dns caches, for example in hotels, that lie when answering DNS requests. So currently, for secure transactions, we rely on the SSL cert authority chain, which is a database of, essentially, root keys, which need to be tracked. Securely. Forever. You're right that this isn't great, but there's no better alternative - this is as good as it gets, unless you know something I don't. (pun intended) The good thing about having DNSSEC is that now we have two security systems an attacker needs to suborn at the same time in order to fully phork your web browser. -- to unsubscribe send a message to namedroppers-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 Apr 16 11:42:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D754E3A6997; Thu, 16 Apr 2009 11:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 UaTGeelfw5gq; Thu, 16 Apr 2009 11:42:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D54923A6925; Thu, 16 Apr 2009 11:42:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuWSV-000DM8-5c for namedroppers-data0@psg.com; Thu, 16 Apr 2009 18:37:11 +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 1LuWSI-000DKS-4s for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 18:37:04 +0000 Received: from unknown.office.denic.de ([10.122.65.138]) by office.denic.de with esmtp id 1LuWSF-00067k-Uk; Thu, 16 Apr 2009 20:36:55 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id CE58616AAA6; Thu, 16 Apr 2009 20:36:55 +0200 (CEST) Date: Thu, 16 Apr 2009 20:36:55 +0200 From: Peter Koch To: IETF DNSEXT WG Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request Message-ID: <20090416183655.GD12461@unknown.office.denic.de> References: <20090413200002.GB24286@shinkuro.com> <20090414222130.GC24323@x27.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 16, 2009 at 10:48:48AM +0200, Ond??ej Surý wrote: > >> Data included in this new > >> RRTYPE together with the DNSSEC will create a secure chain leading > >> to establishing a secured connection from a client (such as a web > >> browser) to a server.  New RRTYPE will include a flag to indicate > > > > This is a dangerous misconception. RRSIGs are for origin authentication only, > > they do not qualify as certificates for any key material that they happen > > to sign outside of DNSSEC itself.  The chain has a gap. > > Could you please elaborate more? I am quite unsure what you have on your > mind here. What's the difference between this and SSHFP? Both are just > indications that secure communication should(must) be established with > certain public key on server side. What you'd need to achieved the described goal is a link between the key or its fingerprint and the actual host: Some certificate that would associate the former with the latter. DNSSEC, by definition, only gives you the origin authentication, not data correctness. The latter is what you'd need to make sure that a certain key is "rightfully" associated with a particular domain name. Signing a zone only means "I certify that I put _this_ into the zone.". It does not include "... and I checked that the FP (or key) belongs to the host/entity/name". The same property, of course, also holds for A, MX and any other normal RR type, but nobody assumes otherwise. The semantical gap in the chain now is exactly between the DNSSEC signature and the binding of the key/fp to the name or the entity behind that name. It does not matter how large or small that gap is physically or administratively (as in: "the same person is handling TLS certs and the DNS" or "everything is running on the same host anyway") in a particular practical scenario. The remaining risk might be small enough and is very likely much smaller with DNSSEC than without, but from a security or protocol analysis point of view you can't close it with the tools at hand. This is not to argue against the basics of your proposal, just the claim that there is a secure chain I consider wrong (and SSHFP is no different, for that matter). It's important to keep in mind the DNSSEC semantics and the services it offers as well as those it doesn't. Nobody should be faced with unexpected liabilities by applying DNSSEC, or people won't deploy (or will regret afterwards). -Peter {hoping that this also covers Ed's question} -- to unsubscribe send a message to namedroppers-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 Apr 16 12:52:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B9428C1E1; Thu, 16 Apr 2009 12:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 1qzEqPh4Gqi2; Thu, 16 Apr 2009 12:52:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52E8C28C234; Thu, 16 Apr 2009 12:52:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuXX1-000IGI-0k for namedroppers-data0@psg.com; Thu, 16 Apr 2009 19:45:55 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuXWo-000IFj-47 for namedroppers@ops.ietf.org; Thu, 16 Apr 2009 19:45:48 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1LuXWe-0002F0-Df; Thu, 16 Apr 2009 21:45:32 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1LuXWd-0006nC-Vf; Thu, 16 Apr 2009 21:45:31 +0200 From: Florian Weimer To: Paul Vixie Cc: "namedroppers\@ops.ietf.org" Subject: [dnsext] Re: EDNS ping mechanisms References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> Date: Thu, 16 Apr 2009 21:45:31 +0200 In-Reply-To: <70202.1239896047@nsa.vix.com> (Paul Vixie's message of "Thu, 16 Apr 2009 15:34:07 +0000") Message-ID: <87k55kjsbo.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: >> True, if you deploy more forgery resistance techniques like n*queries >> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID >> won't help here. But thanks for clarification. > > adding more queries brings all kinds of questions of its own like which one > to use if the answers aren't all the same. If you want to do more queries, use it to contain the amplification factor of a poisoned cache. What's attractive about a compromised cache is that you invest a few thousands (or billions) of packets, and you affect a large client base. To deal with that, you can avoid caching fast-changing DNS data. So after a cache miss, a fresh RRset is used to answer the first query only. If a second query for the same name arrives, a new upstream query is performed, and if the results match the cached data, it is used for the next 10 queries (say), and after that, for the next 100 queries, and so on (but traditional, TTL-oriented caching can be activated after a few iterations). If there is no match, the new data is stored in the cache and returned to the client, and a counter for fluctuating responses is incremented. This counter is reset to zero when a matching response is encountered, and the process starts from the beginning. If the fluctuation counter is non-zero, queries are treated as cache misses, until the a certain threshold is reached (5?), when the RRset is cached TTL-oriented. Upon TTL expiration, entries are not removed from the cache, but kept so that the ramp-up phase can be avoided despite the fresh upstream query. (I suppose validators are already doing something like that, to save the cryptographic operation if the data hasn't actually changed.) This is somewhat analogous to how ATM cell boundaries are discovered in a bit stream, IIRC. For a resolver which is not vulnerable to TTL-agnostic, Kaminsky-style spoofing attacks, this approach increases the spoofing risk because there are more upstream queries, but the impact of a spoofed response will be a very, very few wrong responses to clients (basically just one, or eleven if you manage to spoof twice in a row). The main problem with this approach is that it might require caching referrals and in-zone authoritaty data separately, which will add considerable overhead to some cache implementation strategies. It is also not clear if the parameters (exponential decay and staturation for the non-fluctuating case, upper limit for the fluctuation counter) can be tweaked so that the upstream query load increases by just an acceptable factor. There is no additional latency for clients if not-fully-confirmed cached RRsets are used for answers, and the additonal upstream query is issued in the background. I can elaborate on this approach if you want (I think I might still have a writeup of the actual algorithm somewhere). But in the end, it's really a "query multiple times" approach, and I think we had ruled that out. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From lbpx@alphasystems.com Thu Apr 16 15:03:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4513A6ED0 for ; Thu, 16 Apr 2009 15:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.22 X-Spam-Level: X-Spam-Status: No, score=-13.22 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 fXgPYgzgnyEm for ; Thu, 16 Apr 2009 15:02:54 -0700 (PDT) Received: from 20151221228.user.veloxzone.com.br (20151221228.user.veloxzone.com.br [201.51.221.228]) by core3.amsl.com (Postfix) with SMTP id DD1453A6979 for ; Thu, 16 Apr 2009 15:02:43 -0700 (PDT) To: " Date: Thu, 16 Apr 2009 15:02:43 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Thu Apr 16 18:21:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909393A69CC; Thu, 16 Apr 2009 18:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.677 X-Spam-Level: * X-Spam-Status: No, score=1.677 tagged_above=-999 required=5 tests=[AWL=-0.296, BAD_ENC_HEADER=1.81, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_32=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 xeyNsj0jXywH; Thu, 16 Apr 2009 18:21:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECA163A68DC; Thu, 16 Apr 2009 18:20:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luce7-000E7R-MS for namedroppers-data0@psg.com; Fri, 17 Apr 2009 01:13:35 +0000 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lucdr-000E6h-B8 for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 01:13:28 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=uINhUF9ImwsNJhBxBtilxRhBM692vh3g9v4t9SDv1J5VsM0y39qW0Pp0grOudbmc; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.96.212] (helo=ix.netcom.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lucdl-0001Yp-AQ; Thu, 16 Apr 2009 21:13:14 -0400 Message-ID: <49E7D79D.7A2A4010@ix.netcom.com> Date: Thu, 16 Apr 2009 18:13:02 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Vixie CC: Michael Graff , =?ISO-8859-1?Q?Ond=3Fej Sur=FD?= , Dan Simon , "namedroppers@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Subject: Re: [dnsext] Re: Request for adoption References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <65829.1239890085@nsa.vix.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688283f5da457751418d2b323999ed950b9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.212 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul and all, Paul makes a very good point, but draws less than accurate final conclusion. It is not known if the costs associated with DNSSEC cannot be justified on a large scale, and with various sorts of miscreant behavior increasing at an alarming rate, I would predict that DNSSEC will vastly improve holding down those costs of policing and managing the effects of these miscreants. It is true as Paul declares that DNSSEC does not aid much if at all in man-in-the-middle attacks, which are also quite pervasive and increasingly so. But kaminsky-style poisoning can at least be easily identified and than a method of dealing with such can than be effected and done so in any number of ways. Paul Vixie wrote: > michael, no flame intended here. path security helps against various kinds > of problems but does nothing for "provider in the middle" attacks where a > hotel middlebox, or a load balancer, or an nxdomain remapper, can break the > "domain owner's intent : rrset content" mapping. this, combined with the > comparatively minor problem of kaminsky-style poisoning or other off-path > attacks, means that there is no reason for confidence in dns's results, > which discourages the development of a whole class of applications. (and > as kaminsky has showed, it also fails to discourage a whole class of > applications who show designed-in misplaced confidence in the answers they > get from dns.) > > i've been flogging dnssec all these years not because of problems that a > larger TID or universal deployment of BCP38 would have solved, but because > i want to enable to creation of new dnssec-aware applications which behave > differently in the presence of signed data. there is no way to justify > dnssec's costs (to date or as projected) on the basis of kaminsky alone. > > --paul > > re: > > > Date: Thu, 16 Apr 2009 05:24:38 -0500 > > From: Michael Graff > > User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) > > To: "Jeffrey A. Williams" > > CC: Ond?ej Surý , > > Dan Simon , > > "namedroppers@ops.ietf.org" , > > doc/ntia DNSSEC , > > USTR General contact > > Subject: [dnsext] Re: Request for adoption > > Sender: owner-namedroppers@ops.ietf.org > > > > Jeffrey A. Williams wrote: > > > Ondrej and all, > > > > > > I hope you will change your mind on this. DNSSEC is unfortunately > > > necessary as miscreants of various sorts are picking the DNS to pieces > > > at the expense of the market place to which you so well and so strongly > > > support. I hope as a responsible person, that you want all users > > > to have a safe and secure Internet experience, and DNSSEC is one > > > step in moving in that positive direction. > > > > I know I'm going to get flamed for this... > > > > From my point of view, I know DNSSEC is happening, and it fixes many DNS > > problems (cache attacks, the infamous ID guessing attacks). However, I > > tend to feel that an increase in transaction security would have also > > fixed many of these attacks. DNSSEC seems, in many ways, to be a very > > complicated and somewhat fragile(*) solution that took 10 years to find > > a problem. > > > > We are, in deploying DNSSEC, requiring that every resolver that wants to > > be secured, track a root key. Forever. Securely. And all the software > > has to be changed to check signatures, or otherwise be DNSSEC aware. > > > > Since many bits of software are changing, why not just make the ID field > > be 128 bits long? EDNS provides the perfect method to do this, and the > > change is far less drastic than DNSSEC. It would cause little to no > > operational impact (other than changing resolvers of course). > > > > I know this is a rather simplistic view on things, but sometimes I > > wonder if we aren't pushing DNSSEC as hard as we can for reasons that no > > one but those pushing so hard can justify. > > > > (*) Fragile, in this case: Zones are no longer one-time configure and > > leave them for years. They have expiration dates. So much new code is > > coming into play, and the failure modes are far more and far harder to > > explain to users. > > > > --Michael > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From mmiller@ak.net Fri Apr 17 06:12:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D233A68DB for ; Fri, 17 Apr 2009 06:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 N8eG4O77gGp2 for ; Fri, 17 Apr 2009 06:12:45 -0700 (PDT) Received: from 190-76-91-63.dyn.movilnet.com.ve (190-76-91-63.dyn.movilnet.com.ve [190.76.91.63]) by core3.amsl.com (Postfix) with SMTP id E959C3A677C for ; Fri, 17 Apr 2009 06:12:39 -0700 (PDT) To: " Date: Fri, 17 Apr 2009 06:12:39 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Fri Apr 17 06:44:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7383A6ABC; Fri, 17 Apr 2009 06:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 pfPfYxD2jpK8; Fri, 17 Apr 2009 06:44:00 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6A0C83A6AC2; Fri, 17 Apr 2009 06:44:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuoF0-000A44-2c for namedroppers-data0@psg.com; Fri, 17 Apr 2009 13:36:26 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuoEm-000A2I-Pt for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 13:36:18 +0000 Received: from [217.41.237.171] (account jim HELO PC0123.bl45.btopenzone.com) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 412206; Fri, 17 Apr 2009 14:35:32 +0100 Cc: Namedroppers , doc/ntia DNSSEC , USTR General contact Message-Id: From: Jim Reid To: Michael Graff In-Reply-To: <49E70766.3030602@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: [dnsext] Bigger QueryIDs Date: Fri, 17 Apr 2009 14:34:58 +0100 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 16, 2009, at 11:24, Michael Graff wrote: > Since many bits of software are changing, why not just make the ID > field > be 128 bits long? Although this would of course make QueryID prediction harder, how will this provide a defence against tampering with the DNS data as responses traverse the network or even detect that one of those attacks has happened? -- to unsubscribe send a message to namedroppers-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 Apr 17 06:44:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3AD3A6CFE; Fri, 17 Apr 2009 06:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[AWL=-3.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553] 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 dyLYOa2RaVcq; Fri, 17 Apr 2009 06:44:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23AFE3A6AC2; Fri, 17 Apr 2009 06:44:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuoF5-000A4X-WC for namedroppers-data0@psg.com; Fri, 17 Apr 2009 13:36:32 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuoEt-000A2I-M0 for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 13:36:25 +0000 Received: from [217.41.237.171] (account jim HELO PC0123.bl45.btopenzone.com) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 412208; Fri, 17 Apr 2009 14:36:05 +0100 Cc: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= , "namedroppers@ops.ietf.org" Message-Id: <0E646939-CFD2-45AA-9478-6235C1A0A1E9@rfc1035.com> From: Jim Reid To: Michael Graff In-Reply-To: <49E71633.7080901@isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: [dnsext] handshakes and bigger QueryIDs Date: Fri, 17 Apr 2009 14:35:15 +0100 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <49E71633.7080901@isc.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 16, 2009, at 12:27, Michael Graff wrote: > Why not have a handshake? Because there's no way of knowing for sure who's hand you're shaking. Or have I missed something? > I know DNS is stateless, and needs to remain so. How would this statelessness be preserved if a handshake was added? -- to unsubscribe send a message to namedroppers-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 Apr 17 06:56:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A693A6C54; Fri, 17 Apr 2009 06:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, 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 TheVohYAcYoX; Fri, 17 Apr 2009 06:56:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE4C33A6A6F; Fri, 17 Apr 2009 06:56:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuoTB-000BcK-1l for namedroppers-data0@psg.com; Fri, 17 Apr 2009 13:51:05 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuoSx-000Ba7-3w; Fri, 17 Apr 2009 13:50:57 +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=gyyCZDYWjrqIsR++TDm8I4Oy6zvjz/L5VqZ2xsgDgwnJNgxqfHfAkg3Q CzPyK3VljqvDQCo9N9yYYTqODaNrIYZZQhO81wZCO53+OU5pdrCap3eEi uOY9bsySPsDYRio; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1239976251; x=1271512251; 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:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[dnse xt]=20WGLC=20summary:=20DNS=20Proxy=20Implementation=20Gu idelines|Date:=20Fri,=2017=20Apr=202009=2014:50:47=20+010 0|Message-ID:=20|To:=20namedroppers@ops. ietf.org|Cc:=20owner-namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20<200904151552.n3FFq5T F050259@stora.ogud.com>|References:=20<200904151552.n3FFq 5TF050259@stora.ogud.com>; bh=bbdLPWhIIRBUxLUZm4nfft/W8NuR9WE3YbuKd058Uo4=; b=SE0xryBerBkKBQMSS5h+l5SoSpCQAGwenE7W3Fjq5hPLtqQoD3U8Ozqa xhiyfB0dDO4NsbNZ4s6lfGKfG0ewD8clRUo4j5fbg9NBX1gigLsrWlNr9 zT36xkACSBumqzJ; X-IronPort-AV: E=Sophos;i="4.40,204,1238972400"; d="scan'208";a="9649138" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 17 Apr 2009 14:50:49 +0100 In-Reply-To: <200904151552.n3FFq5TF050259@stora.ogud.com> References: <200904151552.n3FFq5TF050259@stora.ogud.com> To: namedroppers@ops.ietf.org Cc: owner-namedroppers@ops.ietf.org Subject: Re: [dnsext] WGLC summary: DNS Proxy Implementation Guidelines MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 17 Apr 2009 14:50:47 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 17/04/2009 02:50:48 PM, Serialize complete at 17/04/2009 02:50:48 PM Content-Type: multipart/alternative; boundary="=_alternative 004C0F968025759B_=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. --=_alternative 004C0F968025759B_= Content-Type: text/plain; charset="US-ASCII" > Editor will issue a new version, one week after that version is announced > it will be advanced to the IESG for IETF evaluation. For those that didn't spot it, the revised version was published on 15th April: --8<--8<-- 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 Proxy Implementation Guidelines Author(s) : R. Bellis Filename : draft-ietf-dnsext-dnsproxy-04.txt Pages : 13 Date : 2009-04-15 This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-04.txt --8<--8<-- Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 004C0F968025759B_= Content-Type: text/html; charset="US-ASCII"
> Editor will issue a new version, one week after that version is announced
> it will be advanced to the IESG for IETF evaluation.
For those that didn't spot it, the revised version was published on 15th April:

--8<--8<--
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 Proxy Implementation Guidelines
                Author(s)       : R. Bellis
                Filename        : draft-ietf-dnsext-dnsproxy-04.txt
                Pages           : 13
                Date            : 2009-04-15

This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-04.txt
--8<--8<--

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 004C0F968025759B_=-- -- to unsubscribe send a message to namedroppers-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 Apr 17 07:11:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7253A67E6; Fri, 17 Apr 2009 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.667 X-Spam-Level: X-Spam-Status: No, score=-105.667 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 F4INOqX2yvDs; Fri, 17 Apr 2009 07:11:45 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7CBA83A6B09; Fri, 17 Apr 2009 07:11:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luojc-000DFQ-7U for namedroppers-data0@psg.com; Fri, 17 Apr 2009 14:08:04 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuojO-000DDq-JF for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 14:07:57 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 83F681C0155; Fri, 17 Apr 2009 16:07:49 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7F96D1C011A; Fri, 17 Apr 2009 16:07:49 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 739F47B0032; Fri, 17 Apr 2009 16:07:49 +0200 (CEST) Date: Fri, 17 Apr 2009 16:07:49 +0200 From: Stephane Bortzmeyer To: Michael Graff Cc: namedroppers@ops.ietf.org Subject: [dnsext] Cookies, for bigger IDs (Was: Request for adoption Message-ID: <20090417140749.GA19811@nic.fr> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E70766.3030602@isc.org> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-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 Thu, Apr 16, 2009 at 05:24:38AM -0500, Michael Graff wrote a message of 54 lines which said: > Since many bits of software are changing, why not just make the ID field > be 128 bits long? Good idea, IMHO, and already presented: http://tools.ietf.org/html/draft-eastlake-dnsext-cookies -- to unsubscribe send a message to namedroppers-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 Apr 17 07:17:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0CA3A6DA7; Fri, 17 Apr 2009 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.575 X-Spam-Level: X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=-0.527, 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 QZfSXH+IhFLg; Fri, 17 Apr 2009 07:17:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6527F3A6E07; Fri, 17 Apr 2009 07:15:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luooo-000Dou-2f for namedroppers-data0@psg.com; Fri, 17 Apr 2009 14:13:26 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luoob-000DnM-Nv for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 14:13:19 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3HED1Bs011233; Fri, 17 Apr 2009 07:13:01 -0700 (PDT) Cc: Nicholas Weaver , Michael Graff , Namedroppers , doc/ntia DNSSEC , USTR General contact Message-Id: From: Nicholas Weaver To: Jim Reid In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Bigger QueryIDs Date: Fri, 17 Apr 2009 07:13:01 -0700 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 17, 2009, at 6:34 AM, Jim Reid wrote: > On Apr 16, 2009, at 11:24, Michael Graff wrote: > >> Since many bits of software are changing, why not just make the ID >> field >> be 128 bits long? > > Although this would of course make QueryID prediction harder, how > will this provide a defence against tampering with the DNS data as > responses traverse the network or even detect that one of those > attacks has happened? That is describing an in-path adversary. In path adversaries blow away anything in the absence of cryptography. The problem is, in-path adversaries DON'T REALLY MATTER for DNS. DNS is not the application. The final application is the application. If the final application is vulnerable to an in-path adversary, the adversary can attack the application directly, and doesn't need to bother attacking DNS. If the final application is resistant to an in-path adversary, the application doesn't (and can't) trust DNS. DNSSEC's resistance to in-path attackers doesn't matter for the purposes of looking up names. It only matters if you want a cheaper PKI. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From giant02@ms46.hinet.net Fri Apr 17 07:27:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA023A6A7E; Fri, 17 Apr 2009 07:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.177 X-Spam-Level: X-Spam-Status: No, score=-35.177 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_AHBL_RHSBL=0.692, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 mURA1dIVM5Dk; Fri, 17 Apr 2009 07:27:11 -0700 (PDT) Received: from cable-250-246.zeelandnet.nl (cable-250-246.zeelandnet.nl [82.176.250.246]) by core3.amsl.com (Postfix) with SMTP id C295B3A67E6; Fri, 17 Apr 2009 07:27:09 -0700 (PDT) From: "Homer Blackwell" To: <"dnsext-archive@ietf.org, dnsind-archive@ietf.org, dnsop@ietf.org, drums-archive@ietf.org, eap-archive"@ietf.org> Subject: Rep watches made easy Date: Fri, 17 Apr 2009 10:28:25 -0500 Message-ID: <3689vea155368DRVVdnsext-archive@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A fine designer watch says means refinement and money. A fine, non-expensive designer watch also means intelligence! http://www.febibemiv.cn Visit Diam0nd Reps today and get a terrific designer watch imitation for a uniquely low price. Our watches are the most sought-after in the market, offering you the best performance and unsurpassed quality while allowing you to choose from hundreds of models within dozens of brands! http://www.febibemiv.cn With so many watches that look and work like the real thing, I guarantee you'll have a delicious time finding yours at our store! From owner-namedroppers@ops.ietf.org Fri Apr 17 07:31:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71C03A6AB8; Fri, 17 Apr 2009 07:31:05 -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=[AWL=-1.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553] 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 uVhCd+y-TjLH; Fri, 17 Apr 2009 07:31:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A252E3A6892; Fri, 17 Apr 2009 07:30:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lup2O-000FDr-Jg for namedroppers-data0@psg.com; Fri, 17 Apr 2009 14:27:28 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lup26-000F8d-8w for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 14:27:21 +0000 Received: from [217.41.237.171] (account jim HELO PC0123.bl45.btopenzone.com) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 412230; Fri, 17 Apr 2009 15:27:08 +0100 Cc: Michael Graff , Namedroppers , doc/ntia DNSSEC , USTR General contact Message-Id: <094B8845-7C5B-4D9C-9A16-D6DBF5AC7313@rfc1035.com> From: Jim Reid To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Bigger QueryIDs Date: Fri, 17 Apr 2009 15:26:07 +0100 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 17, 2009, at 15:13, Nicholas Weaver wrote: > The problem is, in-path adversaries DON'T REALLY MATTER for DNS. I disagree. Let's meet in a bar to argue this. > DNS is not the application. That might be the case for 99% of the time today but it might not always be so if/when the DNS gets used for stuff like identity management or ubiquitous RFID tags and so on. -- to unsubscribe send a message to namedroppers-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 Apr 17 07:51:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35593A6BA5; Fri, 17 Apr 2009 07:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 TIi2ueG++uP7; Fri, 17 Apr 2009 07:51:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 171F83A6A1C; Fri, 17 Apr 2009 07:51:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LupME-000H7p-Je for namedroppers-data0@psg.com; Fri, 17 Apr 2009 14:47:58 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LupLz-000H6L-JD for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 14:47:51 +0000 Received: from [192.168.100.15] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id E3209C2DA3; Fri, 17 Apr 2009 15:47:39 +0100 (BST) Date: Fri, 17 Apr 2009 15:46:13 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Jim Reid , Nicholas Weaver cc: Michael Graff , Namedroppers , "doc/ntia DNSSEC" , USTR General contact , Alex Bligh Subject: Re: [dnsext] Bigger QueryIDs Message-ID: <6FAA07B0FB0380599AC083F0@Ximines.local> In-Reply-To: <094B8845-7C5B-4D9C-9A16-D6DBF5AC7313@rfc1035.com> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <094B8845-7C5B-4D9C-9A16-D6DBF5AC7313@rfc1035.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 17 April 2009 15:26:07 +0100 Jim Reid wrote: >> DNS is not the application. > > That might be the case for 99% of the time today but it might not always > be so if/when the DNS gets used for stuff like identity management or > ubiquitous RFID tags and so on. Putting aside Jim's point, and the question of whether or not having multiple layers of protection is valuable, from an operational point of view, even if https://www.example.com/ shows a bad cert, having (e.g.) "traceroute www.example.com" capable of interception is less than helpful. 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 dnshhy@aol.com Fri Apr 17 08:19:33 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50EE83A6E0F for ; Fri, 17 Apr 2009 08:19:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From:VIAGRA \256 Pfizer Inc. ; Fri, 17 Apr 2009 08:19:32 -0700 (PDT) Received: from amerblind.outbound.ed10.com (unknown [81.215.72.194]) by core3.amsl.com (Postfix) with SMTP id 802283A6E1C for ; Fri, 17 Apr 2009 08:19:31 -0700 (PDT) Message-ID: <20090417082046.3090.qmail@amerblind.outbound.ed10.com> To: dnsext-archive@ietf.org Reply-To: dnsext-archive@ietf.org Subject:NT: Message70006 From:VIAGRA ® Pfizer Inc. Date: Fri, 17 Apr 2009 06:20:46 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="@@BOUNDARY" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 This is a multi-part message in MIME format. --@@BOUNDARY Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: 8bit Welcome to WebMD
Welcome to WebMD
 •  Fri, 17 Apr 2009 06:20:46 +0200
New from WebMD: Dear dnsext-archive@ietf.org!Greater tool is easy to get Sign-up today!

You are subscribed as dnsext-archive@ietf.org.
View and manage your WebMD newsletter preferences.
Subscribe to more newsletters. Change/update your email address.

WebMD Privacy Policy
WebMD Office of Privacy
1175 Peachtree Street, Suite 2400, Atlanta, GA 30361
© 2009 WebMD, LLC. All rights reserved.
--@@BOUNDARY Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit New from WebMD: Dear dnsext-archive@ietf.org!Secure and confidential purchase, instant shipping worldwide!. Sign-up today! You are subscribed as dnsext-archive@ietf.org. View and manage your WebMD newsletter preferences. Subscribe to more newsletters. Change/update your email address. WebMD Privacy Policy WebMD Office of Privacy 1175 Peachtree Street, Suite 2400, Atlanta, GA 30361 © 2009 WebMD, LLC. All rights reserved. --@@BOUNDARY-- From owner-namedroppers@ops.ietf.org Fri Apr 17 08:32:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7773A6DF5; Fri, 17 Apr 2009 08:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=-0.504, 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 MsHWgKw+4BVs; Fri, 17 Apr 2009 08:32:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6EE73A6826; Fri, 17 Apr 2009 08:32:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luq0Y-000L6f-Q9 for namedroppers-data0@psg.com; Fri, 17 Apr 2009 15:29:38 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luq0L-000L4u-Lf for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 15:29:32 +0000 Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3HFT6AK018943; Fri, 17 Apr 2009 08:29:06 -0700 (PDT) Cc: Nicholas Weaver , Jim Reid , Michael Graff , Namedroppers , "doc/ntia DNSSEC" , USTR General contact Message-Id: From: Nicholas Weaver To: Alex Bligh In-Reply-To: <6FAA07B0FB0380599AC083F0@Ximines.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Bigger QueryIDs Date: Fri, 17 Apr 2009 08:29:06 -0700 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <094B8845-7C5B-4D9C-9A16-D6DBF5AC7313@rfc1035.com> <6FAA07B0FB0380599AC083F0@Ximines.local> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 17, 2009, at 7:46 AM, Alex Bligh wrote: > > > --On 17 April 2009 15:26:07 +0100 Jim Reid wrote: > >>> DNS is not the application. >> >> That might be the case for 99% of the time today but it might not >> always >> be so if/when the DNS gets used for stuff like identity management or >> ubiquitous RFID tags and so on. > > Putting aside Jim's point, and the question of whether or not having > multiple layers of protection is valuable, from an operational point > of view, even if https://www.example.com/ shows a bad cert, > having (e.g.) "traceroute www.example.com" capable of interception > is less > than helpful. And if DNSSEC was free, I'd agree with you. However, there are tons of applications which are not secure against a MitM, and DNSSEC, improperly deployed, will cause all of those to stop working because most DNSSEC failures are not going to be attacks, but screwups. This is why I actually advocate the following policy for DNSSEC for stub resolvers: If, for any reason, the DNSSEC signature validation fails (out of date, wrong signature, no trust anchor, no DNSSEC information at all) on a normal application lookup, the stub resolver conducts its own recursive lookup, bypassing its recursive server, and accepts that. Any true DNSSEC-aware application will obviously be unable to get the key data it needs (so that all works "secure" and fails), but all the non-DNSSEC-aware applications will still get the name information, and it counters the one adversary which is in-path on DNS but out-of-path on the application traffic: the ISP's recursive resolver. However, unless an application is specifically DNSSEC-aware (not just doing normal lookup, but asking for keying material out of DNS and validating it with DNSSEC), turning on DNSSEC in this model provides almost no increase in real-world security, it just makes sure that it doesn't provide a huge decrease in real-world availability. And as for your specific example, traceroute itself isn't secure against an in-path adversary. So who cares if traceroute gets "www.example.com "'s IP correct? -- to unsubscribe send a message to namedroppers-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 Apr 17 09:16:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942203A692C; Fri, 17 Apr 2009 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 cq7LYHyA75MO; Fri, 17 Apr 2009 09:16:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEF9A3A680F; Fri, 17 Apr 2009 09:16:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuqfW-000ObS-Hs for namedroppers-data0@psg.com; Fri, 17 Apr 2009 16:11:58 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuqfJ-000OaT-Mn for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 16:11:52 +0000 Received: from [192.168.100.15] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 193C0C2DA3; Fri, 17 Apr 2009 17:11:43 +0100 (BST) Date: Fri, 17 Apr 2009 17:10:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , Jim Reid , Michael Graff , Namedroppers , "doc/ntia DNSSEC" , USTR General contact , Alex Bligh Subject: Re: [dnsext] Bigger QueryIDs Message-ID: <0C87D41F13FF62489B580B30@Ximines.local> In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <094B8845-7C5B-4D9C-9A16-D6DBF5AC7313@rfc1035.com> <6FAA07B0FB0380599AC083F0@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 17 April 2009 08:29:06 -0700 Nicholas Weaver wrote: > And as for your specific example, traceroute itself isn't secure against > an in-path adversary. So who cares if traceroute gets > "www.example.com"'s IP correct? I was being slightly elliptic. My point was that it even tools you would not think of as needing any form of MtiM protection etc. benefit. After all, traceroute is a useful diagnostic tool today. At the minimum it tells you that either X is the route taken to a specific host, OR someone along the route is faking / disguising that route by producing the relevant ICMP responses. Whilst we all know BGP route injection attacks are possible, they are (currently) rare. Heuristically, traceroute is useful. If you build in protection /only/ at the app-to-app layer, then I can see two probably results, assuming prevalence of DNS attacks. 1. When you see a cert that doesn't match or whatever, you have no or fewer ways of debugging it, as you trust the underlying infrastructure less. 2. Whilst the app-to-app protection will, if successfully deployed (*) make impersonation attacks harder, DNS poisoning etc. can be used for an easy DoS vector or vector for attacks on unsuccessful deployments. (*) = recent activity has shown that (e.g.) SSL certificates provide poor protection when CAs are prepared to hand out certs to all and sundry. SSL also comes at a cost. So your argument that DNSSEC can be badly deployed, and comes at a cost applies elsewhere in the stack too. Of course there are questions of degree here. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 17 11:16:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E140A28C19C; Fri, 17 Apr 2009 11:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[AWL=-0.902, 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 v1X0oEHUN7hc; Fri, 17 Apr 2009 11:16:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0837F28C198; Fri, 17 Apr 2009 11:16:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LusWS-0008ff-Vy for namedroppers-data0@psg.com; Fri, 17 Apr 2009 18:10:44 +0000 Received: from [64.18.14.181] (helo=chip3og58.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LusWG-0008VY-S4 for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 18:10:38 +0000 Received: from source ([64.89.228.229]) by chip3ob58.postini.com ([64.18.6.12]) with SMTP ID DSNKSejF00y2CHP/M28SXEqmDFOXc9gPsTaZ@postini.com; Fri, 17 Apr 2009 11:10:32 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 812401B8418; Fri, 17 Apr 2009 11:09:35 -0700 (PDT) Received: from uma.here (71.32.40.139) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 17 Apr 2009 11:09:22 -0700 CC: Jim Reid , Michael Graff , Namedroppers , doc/ntia DNSSEC , USTR General contact Message-ID: <0BA7AB7D-2E3C-40CC-8E07-23168DE4513B@nominum.com> From: Ted Lemon To: Nicholas Weaver In-Reply-To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Bigger QueryIDs Date: Fri, 17 Apr 2009 11:09:20 -0700 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 17, 2009, at 7:13 AM, Nicholas Weaver wrote: > The problem is, in-path adversaries DON'T REALLY MATTER for DNS. DNS > is not the application. The final application is the application. You've repeated this over and over again, but I don't think it's any more true than it was the first time you said it. It's been demonstrated that the most commonly-used security technology out there, SSL, is vulnerable if the DNS is vulnerable, and is less vulnerable if it is not. So the question is not whether securing DNS against in-path adversaries makes anything more secure, but rather whether the degree of security it adds justifies the cost of implementation. -- to unsubscribe send a message to namedroppers-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 Apr 17 11:42:17 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049EA3A6E1F; Fri, 17 Apr 2009 11:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.293, 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 gvtdFUn-agIv; Fri, 17 Apr 2009 11:42:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B9DC3A69E4; Fri, 17 Apr 2009 11:41:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lusvb-000AvM-Ce for namedroppers-data0@psg.com; Fri, 17 Apr 2009 18:36:43 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LusvO-000AuR-Ep for namedroppers@ops.ietf.org; Fri, 17 Apr 2009 18:36:36 +0000 Received: from [0.0.0.0] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3HIaRhE076177; Fri, 17 Apr 2009 14:36:27 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <0BA7AB7D-2E3C-40CC-8E07-23168DE4513B@nominum.com> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <0BA7AB7D-2E3C-40CC-8E07-23168DE4513B@nominum.com> Date: Fri, 17 Apr 2009 14:33:20 -0400 To: Namedroppers From: Edward Lewis Subject: Re: [dnsext] Bigger QueryIDs Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 11:09 -0700 4/17/09, Ted Lemon wrote: >On Apr 17, 2009, at 7:13 AM, Nicholas Weaver wrote: >> The problem is, in-path adversaries DON'T REALLY MATTER for DNS. DNS >> is not the application. The final application is the application. > >You've repeated this over and over again, but I don't think it's any >more true than it was the first time you said it. I agree with Ted, both about the fallacy and the repetition of it. I've not responded before because I didn't want to take time to explain the reasons myself, but just for the record, forged (etc.) records sent by elements "in-path" matter as much as forged records from any other source. If the application relies on an environmental element that is not safe, the application is not safe. An application can take many steps to make itself safe but if the environment is malicious, the application won't succeed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From atg@adsl.tie.cl Fri Apr 17 15:55:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330B228C1DD; Fri, 17 Apr 2009 15:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 NACHDVwiYGqa; Fri, 17 Apr 2009 15:55:02 -0700 (PDT) Received: from 190-82-159-122.adsl.tie.cl (190-82-159-122.adsl.tie.cl [190.82.159.122]) by core3.amsl.com (Postfix) with ESMTP id 4148528C1ED; Fri, 17 Apr 2009 15:54:58 -0700 (PDT) Message-ID: Date: Fri, 17 Apr 2009 18:56:10 -0500 From: "Cramer Blake" TO: <"ccamp@ietf.org, imrg-request@ietf.org, asrg@ietf.org, dnsext-archive@ietf.org, grow@ietf.org, iesg-secretary@ietf.org, ietf-minutes@ietf.org, ietf-secretariat"@ietf.org> Subject: watch for a Gift! Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Why waste your hard-earned money on an expensive watch when you can have the next best thing for a tenth of its price? http://www.yuxowalic.cn At Diam0nd Reps we make it easy to get a Rolex, Cartier, Bvlgari or any brand name that you think of. As long as it is considered a high class watch, you will find it in our one of a kind store! http://www.yuxowalic.cn Check out our extensive inventory and enjoy the fastest shipping available online! See you at Diam0nd Reps! From owner-namedroppers@ops.ietf.org Fri Apr 17 18:19:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D923A680B; Fri, 17 Apr 2009 18:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=0.918, 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 QEbKKrYP6mfL; Fri, 17 Apr 2009 18:19:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D86903A672F; Fri, 17 Apr 2009 18:19:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luz5j-000I0K-CS for namedroppers-data0@psg.com; Sat, 18 Apr 2009 01:11:35 +0000 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luz5W-000HzV-Fv for namedroppers@ops.ietf.org; Sat, 18 Apr 2009 01:11:28 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ALqbiy0sCc49C3YG9/a8s9JjJmXONu2N6YSASsB0nV8VZI5KybfYI6P2Z6P/LZyd; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.240] (helo=ix.netcom.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Luz5M-0001Wb-QQ; Fri, 17 Apr 2009 21:11:13 -0400 Message-ID: <49E928A6.E6D02656@ix.netcom.com> Date: Fri, 17 Apr 2009 18:11:02 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicholas Weaver CC: Jim Reid , Michael Graff , Namedroppers , doc/ntia DNSSEC , USTR General contact Subject: Re: [dnsext] Bigger QueryIDs References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606883a35a433ceedbcd2e37a75bc08cf5ad3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.240 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Nicholas and all, Good points! Application security obviously is important, and using secure coding techniques is very advisable. Developing means of detecting less than secure applications is also advisable if not paramount if global financial trade is to become far more safe than it is today. Unfortunately this will require very carefully crafted regulation, which I don't like but recognize that the private sector via self regulation is unwilling to do our/themselves to the extent necessary. This said, I am not yet confident that government(s) are truly up to the task or have the political will as such regulations will be strongly opposed from many business sectors. Nicholas Weaver wrote: > On Apr 17, 2009, at 6:34 AM, Jim Reid wrote: > > > On Apr 16, 2009, at 11:24, Michael Graff wrote: > > > >> Since many bits of software are changing, why not just make the ID > >> field > >> be 128 bits long? > > > > Although this would of course make QueryID prediction harder, how > > will this provide a defence against tampering with the DNS data as > > responses traverse the network or even detect that one of those > > attacks has happened? > > That is describing an in-path adversary. > > In path adversaries blow away anything in the absence of cryptography. > > The problem is, in-path adversaries DON'T REALLY MATTER for DNS. DNS > is not the application. The final application is the application. > > If the final application is vulnerable to an in-path adversary, the > adversary can attack the application directly, and doesn't need to > bother attacking DNS. > > If the final application is resistant to an in-path adversary, the > application doesn't (and can't) trust DNS. > > DNSSEC's resistance to in-path attackers doesn't matter for the > purposes of looking up names. It only matters if you want a cheaper > PKI. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-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 Apr 17 18:22:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D623A680B; Fri, 17 Apr 2009 18:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.453 X-Spam-Level: X-Spam-Status: No, score=0.453 tagged_above=-999 required=5 tests=[AWL=0.890, 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 qfUw0VX36RXA; Fri, 17 Apr 2009 18:22:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C5643A672F; Fri, 17 Apr 2009 18:22:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuzCE-000IVv-6O for namedroppers-data0@psg.com; Sat, 18 Apr 2009 01:18:18 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuzC1-000IUs-3M for namedroppers@ops.ietf.org; Sat, 18 Apr 2009 01:18:11 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=FWgCuNZXlGyJMvkrM8BcEKFmSIyQ2jOBPOVwXXUflfG7ckajM2kgtl/CI+vEk0PN; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.97.240] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LuzBr-0002AY-Ug; Fri, 17 Apr 2009 21:17:56 -0400 Message-ID: <49E92A39.CD8A2A09@ix.netcom.com> Date: Fri, 17 Apr 2009 18:17:46 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Reid CC: Nicholas Weaver , Michael Graff , Namedroppers , doc/ntia DNSSEC , USTR General contact Subject: Re: [dnsext] Bigger QueryIDs References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <094B8845-7C5B-4D9C-9A16-D6DBF5AC7313@rfc1035.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688906ae0c0db28d21429bdd9871f72a7ec350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.97.240 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Jim and all, Also a goo point, but at present a weak one. Yet what you seem to be suggesting might be a means by which good and effective regulation could be crafted around. Still if so, opposition would be significant and with a number of very good arguments in support. Jim Reid wrote: > On Apr 17, 2009, at 15:13, Nicholas Weaver wrote: > > > The problem is, in-path adversaries DON'T REALLY MATTER for DNS. > > I disagree. Let's meet in a bar to argue this. > > > DNS is not the application. > > That might be the case for 99% of the time today but it might not > always be so if/when the DNS gets used for stuff like identity > management or ubiquitous RFID tags and so on. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-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 Apr 17 19:14:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80D43A67E6; Fri, 17 Apr 2009 19:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=-0.778, 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 THYbNvmH8OIc; Fri, 17 Apr 2009 19:14:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0219D3A6A41; Fri, 17 Apr 2009 19:14:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Luzzo-000N3B-Lj for namedroppers-data0@psg.com; Sat, 18 Apr 2009 02:09:32 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuzyT-000Mtx-Fx for namedroppers@ops.ietf.org; Sat, 18 Apr 2009 02:08:15 +0000 Received: from drugs.dv.isc.org (unknown [123.211.102.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 55EECE6029; Sat, 18 Apr 2009 02:08:08 +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.3/8.14.3) with ESMTP id n3I281Cj082133; Sat, 18 Apr 2009 12:08:02 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200904180208.n3I281Cj082133@drugs.dv.isc.org> To: Ray.Bellis@nominet.org.uk Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] WGLC summary: DNS Proxy Implementation Guidelines In-reply-to: Your message of "Fri, 17 Apr 2009 14:50:47 +0100." Date: Sat, 18 Apr 2009 12:08:01 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Is 28 correct for IPv6? Method 1 above will cause compatibility problems with EDNS0 unless the DNS client is configured to advertise an EDNS0 buffer size limited to 28 octets less than the MTU. Note that RFC 2671 does recommend that the path MTU should be taken into account when using EDNS0. -- 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 kass@afpsecurite.com Sat Apr 18 07:06:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0B93A6864 for ; Sat, 18 Apr 2009 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.557 X-Spam-Level: X-Spam-Status: No, score=-8.557 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_TW=1.335, HELO_MISMATCH_TW=0.994, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 GziF9spwSm-I for ; Sat, 18 Apr 2009 07:06:34 -0700 (PDT) Received: from airway.com.tw (unknown [189.74.225.225]) by core3.amsl.com (Postfix) with SMTP id 5516A3A68B9 for ; Sat, 18 Apr 2009 07:06:30 -0700 (PDT) To: " Date: Sat, 18 Apr 2009 07:06:30 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From mack5@agri-fab.com Mon Apr 20 01:13:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E7D3A6925 for ; Mon, 20 Apr 2009 01:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.163 X-Spam-Level: X-Spam-Status: No, score=-29.163 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 nBaE+Nh7z9XU for ; Mon, 20 Apr 2009 01:13:24 -0700 (PDT) Received: from 152.42.83-79.rev.gaoland.net (152.42.83-79.rev.gaoland.net [79.83.42.152]) by core3.amsl.com (Postfix) with SMTP id 99A303A6991 for ; Mon, 20 Apr 2009 01:13:23 -0700 (PDT) To: " Date: Mon, 20 Apr 2009 01:13:23 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Mon Apr 20 05:17:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B4A3A6D7C; Mon, 20 Apr 2009 05:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.191 X-Spam-Level: **** X-Spam-Status: No, score=4.191 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 Pe4bo6Ki8PO1; Mon, 20 Apr 2009 05:17:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B56123A6A34; Mon, 20 Apr 2009 05:17:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvsIa-000N1J-2k for namedroppers-data0@psg.com; Mon, 20 Apr 2009 12:08:32 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvsIN-000N0F-9H for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 12:08:25 +0000 Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1LvsIG-0007VU-6f; Mon, 20 Apr 2009 13:08:12 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1LvsIF-00033t-9T; Mon, 20 Apr 2009 13:08:11 +0100 Message-ID: <9D43916D3C5846E9B2452967180A5416@localhost> From: "George Barwood" To: "Paul Vixie" , References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Date: Mon, 20 Apr 2009 13:08:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Paul Vixie" To: Sent: Thursday, April 16, 2009 4:34 PM Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) >> >> You cannot do that without backwards compatibility. And if you keep >> >> backwards compatibility you are prone to downgrade attacks, ie.: >> > >> > Actually, you are NOT prone to downgrade attacks. >> >> True, if you deploy more forgery resistance techniques like n*queries >> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID >> won't help here. But thanks for clarification. > > adding more queries brings all kinds of questions of its own like which > one > to use if the answers aren't all the same. also, punishing folks who > don't > upgrade by increasing their load. (dns-0x20 does this also, but the size > of > the punished population is smaller, being limited only to folks who > downcase > or upcase QNAMEs in their responses, which was never prohibited or > required.) There is a trade-off, better security versus more DNS packets. The question of what to do if answers aren't all the same is addressed in my draft https://datatracker.ietf.org/drafts/draft-barwood-dnsext-fr-resolver-mitigations/ > i think that any effort beyond dns-0x20 to secure against off-path > attackers > is misplaced. Can you give reasons? I can think of a few, although I don't think they are valid, there may be more: (i) The actual situation ( provided ISPs use port randomization ), is not too bad. Answer: as an IT manager, I would wish to install software that is as secure as possible, not relying on unknown third parties to operate as securely as possible. (ii) The increased load on DNS servers/networks is unacceptable. Answer: I don't believe this is true. But please state this explicitly if you think this is the case. (iii) FUD : any change carries some risk. Answer: it's true that implementing repetition in a resolver is quite complex. But I think it is doable. (iv) It's better to solve the problem with BGP. Answer: I'm afraid this is somewhat outside my knowledge, but answer is same as for (i). > dns must be secured end to end, which will not only enable a > new class of dnssec-aware applications, but obviate the need to secure dns > hop by hop. The case for DNSSEC, as has been observed by Nicholas Weaver on many occasions, is quite weak/unclear. It is the application that must be secured end to end, and this is a cost/performance trade off. Can you give an example of such a dnssec-aware application? > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > ----- Original Message ----- From: "Paul Vixie" To: Sent: Thursday, April 16, 2009 4:34 PM Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) >> >> You cannot do that without backwards compatibility. And if you keep >> >> backwards compatibility you are prone to downgrade attacks, ie.: >> > >> > Actually, you are NOT prone to downgrade attacks. >> >> True, if you deploy more forgery resistance techniques like n*queries >> (which could be deployed without 128bit ID/EDNS ping). Simple 128bit ID >> won't help here. But thanks for clarification. > > adding more queries brings all kinds of questions of its own like which > one > to use if the answers aren't all the same. also, punishing folks who > don't > upgrade by increasing their load. (dns-0x20 does this also, but the size > of > the punished population is smaller, being limited only to folks who > downcase > or upcase QNAMEs in their responses, which was never prohibited or > required.) > > i think that any effort beyond dns-0x20 to secure against off-path > attackers > is misplaced. dns must be secured end to end, which will not only enable > a > new class of dnssec-aware applications, but obviate the need to secure dns > hop by hop. > > -- > to 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 Apr 20 07:54:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24703A6C6F; Mon, 20 Apr 2009 07:54:41 -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 ykECD+fXEJ0L; Mon, 20 Apr 2009 07:54:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D48E23A6C8C; Mon, 20 Apr 2009 07:54:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvunX-000B6w-P3 for namedroppers-data0@psg.com; Mon, 20 Apr 2009 14:48:39 +0000 Received: from [74.125.78.24] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvun6-000B34-70 for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 14:48:22 +0000 Received: by ey-out-2122.google.com with SMTP id d26so161056eyd.65 for ; Mon, 20 Apr 2009 07:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=9QpgOlvzVVcJYgS5BAq9npDRxM4nE8NmEoPa7ffKXe8=; b=qaQEmPFKHRz+H5PQwoSIeQKSovHhitgOoYwHQggHw6LAUrWu42zXCWJMhTlj5jBVfU LfoQ68j7PAlMDPS9k0S76HvIkuIXiD7KrnLJhQXPPpuOhblZPkZRRzXZPRoz/7i6TOOe n6MkhArEe4ReU/iT6jFHWRkC+vf/Ent9ocXo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=f7SkV+6FJzWR02hGcB+bYFYGKyu1pYDs2V+2+dZF1Q1frikunrqmMlub3IsqqJvW/V S0xBybtRtuiPqwN+pUvGl0sJaOvOacXV1M1RJhc+Vhw4NfSKbFfESX9mrCXcrGdRpRRZ C8tO615MlqYDtBON4M8SD6GiUHAGVwleiG9jc= MIME-Version: 1.0 Received: by 10.210.59.3 with SMTP id h3mr3781375eba.86.1240238890451; Mon, 20 Apr 2009 07:48:10 -0700 (PDT) In-Reply-To: <70202.1239896047@nsa.vix.com> References: <49DB20B8.7020505@cryptocom.ru> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> From: bert hubert Date: Mon, 20 Apr 2009 16:47:55 +0200 Message-ID: <3efd34cc0904200747q480faf5eg5f0f74fe3505e1e4@mail.gmail.com> Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) To: Paul Vixie Cc: "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 16, 2009 at 5:34 PM, Paul Vixie wrote: > i think that any effort beyond dns-0x20 to secure against off-path attack= ers > is misplaced. =A0dns must be secured end to end, which will not only enab= le a > new class of dnssec-aware applications, but obviate the need to secure dn= s > hop by hop. Well.. Be that as it may, EDNS-PING is an easy upgrade. In fact, it is out there today. In addition, as far as I understand it, DNSSEC can still be disrupted easily enough at the delegation point if DNS responses can be spoofed. This might lead to prolonged (perceived) downtime. This in turn leads to people asking the question what good DNSSEC is if it can be spoofed into downtime this easily (either in-path or out-of-path). So even if you think DNSSEC is the answer to all your questions, it may turn out that it isn't in practice. Bert -- to unsubscribe send a message to namedroppers-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 Apr 20 08:17:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0E53A6D01; Mon, 20 Apr 2009 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.543 X-Spam-Level: X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=-0.495, 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 TJTFY8UfjGPu; Mon, 20 Apr 2009 08:17:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5D12A3A6B2B; Mon, 20 Apr 2009 08:17:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvvBh-000E4y-Eb for namedroppers-data0@psg.com; Mon, 20 Apr 2009 15:13:37 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvvBT-000E3I-UR for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 15:13:30 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3KFDFnX013542; Mon, 20 Apr 2009 08:13:18 -0700 (PDT) From: Nicholas Weaver To: "George Barwood" In-Reply-To: <9D43916D3C5846E9B2452967180A5416@localhost> Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) X-Priority: 3 References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <9D43916D3C5846E9B2452967180A5416@localhost> Message-Id: <93FB9312-A851-4F5F-87E0-BB1C32299342@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 08:13:15 -0700 Cc: Nicholas Weaver , "Paul Vixie" , X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 20, 2009, at 5:08 AM, George Barwood wrote: > > Can you give an example of such a dnssec-aware application? A good example would be an extension to SSH. On "leap of faith" (first time encountering a new key), an DNSSEC- aware ssh client could fetch the key through DNS and validate the DNSSEC signature, rather than just trusting the key the first time. DNSSEC is really a PKI infrastructure with one huge important difference compared with all the other PKI schemes out there: Rather than the authority signing for you a specific certificate, the authority is signing a full signing certificate (making you an authority as well), but with your authority limited to within the domain name you control, automatically matching your key-signing authority with your existing name-creation authority. This provides several advantages in usability over the certificate schemes used in, say, HTTPS: a) It reduces the proliferation of trust anchors. Look at firefox: There an an absolute truckload of certificate authorities listed in a default install. If any one of these certificate authorities have a problem, HTTPS has a problem. Yet it still doesn't include important ones (like the DOD CAs!). Compare this with DNSSEC where, once the right political problems are solved, there becomes one trust anchor with the root. b) It aligns trust in signatures with existing relationships/trust in names. c) It is vastly cheaper than other PKI schemes. Because you are given a signing certificate, you no longer need to go back to verisign or thawte or any of the other companies when you want to change a certificate on an end host, add a new subname or subdomain, use a different type of certificate (code signing vs mail signing vs TLS), etc. There are TONS of things I could do with such a cheap PKI. EG, just opportunistically encrypt ALL traffic between end-hosts by using IPSec ubiquitously, with DNSSEC to get the keys. Or have the web browser accept self-signed certificates on port 80, IFF it can validate the certificate through DNSSEC. But it requires understanding that DNSSEC's primary value is providing this PKI to secure Name->Key mappings, not securing Name->Address mappings. It also means that providing a good API for doing these lookups, regardless of the state of the stub resolver and recursive resolver, with useful error reporting when failures happen, is probably the best next step in getting DNSSEC adopted, because thats whats needed for applications to really take advantage of DNSSEC. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 20 09:03:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42E53A6DBD; Mon, 20 Apr 2009 09:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 70LEPtBEiuDb; Mon, 20 Apr 2009 09:03:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E913F3A6F41; Mon, 20 Apr 2009 09:03:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvvtG-000IMG-PN for namedroppers-data0@psg.com; Mon, 20 Apr 2009 15:58:38 +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 1Lvvt2-000ILb-Ei for namedroppers@psg.com; Mon, 20 Apr 2009 15:58:31 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3KFwKpw063201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Apr 2009 08:58:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 20 Apr 2009 08:57:45 -0700 To: namedroppers@psg.com From: Paul Hoffman Subject: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Greetings again. draft-ietf-dnsext-dnssec-rsasha256 is probably not ready for IETF Last Call. I have read it again more carefully because I am preparing some other related drafts, and the coverage of NSEC3 is contradictory to the point where I can't figure out what is wanted. For reference: ========================================================== 5.2. Support for NSEC3 Denial of Existence RFC 5155 [RFC5155] defines new algorithm identifiers for existing signing algorithms, to indicate that zones signed with these algorithm identifiers can use NSEC3 as well as NSEC records to provide denial of existence. That mechanism was chosen to protect implementations predating RFC5155 from encountering resource records they could not know about. This document does not define such algorithm aliases, and support for NSEC3 denial of existence is implicitly signaled with support for one of the algorithms defined in this document. 5.2.1. NSEC3 in Authoritative servers An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence. 5.2.2. NSEC3 in Validators A DNSSEC validator that implements RSA/SHA-2 MUST be able to handle both NSEC and NSEC3 [RFC5155] negative answers. If this is not the case, the validator MUST treat a zone signed with RSA/SHA-256 or RSA/ SHA-512 as signed with an unknown algorithm, and thus as insecure. ========================================================== There are two sets of contradictory statements: a) Mandatory support "support for NSEC3 denial of existence is implicitly signaled with support for one of the algorithms defined in this document" vs. "An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence." b) Confused MUST "A DNSSEC validator that implements RSA/SHA-2 MUST be able to handle both NSEC and NSEC3 [RFC5155] negative answers" vs. "If this is not the case..." In both cases, the second statement is impossible based on the first statement. In order to increase clarity, I propose that 5.2 be rewritten, without subsections, as follows: 5.2. Support for NSEC3 Denial of Existence RFC 5155 [RFC5155] defines new algorithm identifiers for existing signing algorithms, to indicate that zones signed with these algorithm identifiers can use NSEC3 as well as NSEC records to provide denial of existence. That mechanism was chosen to protect implementations predating RFC5155 from encountering resource records they could not know about. This document does not define such algorithm aliases. A DNSSEC validator that implements RSA/SHA-2 MUST be able to handle both NSEC and NSEC3 [RFC5155] negative answers. An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence. --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 Apr 20 09:49:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82F928C162; Mon, 20 Apr 2009 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.58 X-Spam-Level: X-Spam-Status: No, score=-104.58 tagged_above=-999 required=5 tests=[AWL=2.019, 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 euC2tapIZRrd; Mon, 20 Apr 2009 09:49:33 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 01E1C3A6FA5; Mon, 20 Apr 2009 09:49:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvwax-000MsB-Jx for namedroppers-data0@psg.com; Mon, 20 Apr 2009 16:43:47 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvwak-000Mqn-D3 for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 16:43:40 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 936BDA1017 for ; Mon, 20 Apr 2009 16:43:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: Your message of "Mon, 20 Apr 2009 13:08:05 +0100." <9D43916D3C5846E9B2452967180A5416@localhost> References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <9D43916D3C5846E9B2452967180A5416@localhost> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 20 Apr 2009 16:43:28 +0000 Message-ID: <26901.1240245808@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: "George Barwood" > Date: Mon, 20 Apr 2009 13:08:05 +0100 > > There is a trade-off, better security versus more DNS packets. nope, that's not the tradeoff we'd be making. -- to unsubscribe send a message to namedroppers-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 Apr 20 09:49:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1CF3A6F89; Mon, 20 Apr 2009 09:49:49 -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 4-FWizEeOAk0; Mon, 20 Apr 2009 09:49:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8E0033A6FB2; Mon, 20 Apr 2009 09:49:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvwcT-000MzJ-0G for namedroppers-data0@psg.com; Mon, 20 Apr 2009 16:45:21 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvwcF-000Mxm-0T for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 16:45:14 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9589FA1037; Mon, 20 Apr 2009 16:45:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bert hubert cc: "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: Your message of "Mon, 20 Apr 2009 15:58:03 +0200." <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> References: <49DB20B8.7020505@cryptocom.ru> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 20 Apr 2009 16:45:06 +0000 Message-ID: <26970.1240245906@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > From: bert hubert > Date: Mon, 20 Apr 2009 15:58:03 +0200 > > Well.. Be that as it may, EDNS-PING is an easy upgrade. In fact, it is > out there today. ... this is an easy upgrade for an implementor, or for a single operator. it is NOT an easy upgrade for the industry, nor will it be if it happens to try to occur unplanned/organically. -- to unsubscribe send a message to namedroppers-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 Apr 20 10:11:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D9E3A69DF; Mon, 20 Apr 2009 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.633 X-Spam-Level: X-Spam-Status: No, score=-104.633 tagged_above=-999 required=5 tests=[AWL=1.966, 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 Lr5Ea6bv8Rd2; Mon, 20 Apr 2009 10:11:11 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 989933A696F; Mon, 20 Apr 2009 10:11:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvwxj-000Oxb-IY for namedroppers-data0@psg.com; Mon, 20 Apr 2009 17:07:19 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvwxS-000OwM-Hd for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 17:07:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D6766A103E; Mon, 20 Apr 2009 17:07:01 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bert hubert cc: "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: Your message of "Mon, 20 Apr 2009 19:04:54 +0200." <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> References: <49DB20B8.7020505@cryptocom.ru> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 20 Apr 2009 17:07:01 +0000 Message-ID: <28085.1240247221@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > So I am unsure where you base your claims on that it is not an easy > upgrade - almost nobody noticed. the industry is much larger, in extent and in time, than you're measuring. -- to unsubscribe send a message to namedroppers-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 Apr 20 10:32:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A371A28C2DC; Mon, 20 Apr 2009 10:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.465 X-Spam-Level: X-Spam-Status: No, score=-4.465 tagged_above=-999 required=5 tests=[AWL=-1.166, 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 vL8XEJm12QJe; Mon, 20 Apr 2009 10:32:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B363628C2CE; Mon, 20 Apr 2009 10:32:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvxFS-0000RC-ES for namedroppers-data0@psg.com; Mon, 20 Apr 2009 17:25:38 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvxF6-0000O3-T6 for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 17:25:31 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34346) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1LvxF4-0006M8-Ig (Exim 4.70) (return-path ); Mon, 20 Apr 2009 18:25:14 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LvxF4-0003TZ-P7 (Exim 4.67) (return-path ); Mon, 20 Apr 2009 18:25:14 +0100 Date: Mon, 20 Apr 2009 18:25:14 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Michael Graff cc: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Re: Request for adoption In-Reply-To: <49E71633.7080901@isc.org> Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <49E71633.7080901@isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, 16 Apr 2009, Michael Graff wrote: > > Why not have a handshake? I know DNS is stateless, and needs to remain > so. We're already multiplying traffic by something obscene in using > DNSSEC, it would hardly be wrong to either add such a handshake, or > retransmit more than once with a 128-bit keyid, and each retransmission > using a different 16-bit query ID, and compare the results. You can't compare latency and bandwidth like that. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-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 Apr 20 10:33:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B33B28C2D1; Mon, 20 Apr 2009 10:33:22 -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 CaurUyzki9II; Mon, 20 Apr 2009 10:33:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A48228C2CE; Mon, 20 Apr 2009 10:33:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvwvq-000Onj-Vp for namedroppers-data0@psg.com; Mon, 20 Apr 2009 17:05:23 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvwve-000OmS-HM for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 17:05:16 +0000 Received: by ewy2 with SMTP id 2so1820681ewy.41 for ; Mon, 20 Apr 2009 10:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=3D8b0Vze1yTj/PjkX/5Ev12FpWOMQaYvRQrXPbB7nxA=; b=p/5qlEmTeRPnlgMG3UOO62OudoLC6LX0BTO4PeWHThrpV7xnwKxU0Eo4r8DtXAPK9D jPLXV0POzrYCZwJOi8W9JrINjiIJLRGjfVoguKCKG+aGHp0yKW9v0kR7a8ldW5NYoXfb CvJ64YiUafIahz7+X74J/BKUL1h3AxW55B1hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ntB4zLJyiDiuOIAHSeQdMfzQR8J98cpeuSNqmXdS2IPR9y9w1HQS94JtQ28eo5Eng2 VWtZH1FwSE8TRTG2uTKD2Q+aYHLKJ7ary5E/E8GQl+if/Wk664aqzSxH4dD2Zux7Qdwf XZ8ZbGXcFS+hSmcKgUV+m9FjCpMVc1DL75Q/4= MIME-Version: 1.0 Received: by 10.210.139.15 with SMTP id m15mr5039763ebd.38.1240247109103; Mon, 20 Apr 2009 10:05:09 -0700 (PDT) In-Reply-To: <26970.1240245906@nsa.vix.com> References: <49DB20B8.7020505@cryptocom.ru> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> From: bert hubert Date: Mon, 20 Apr 2009 19:04:54 +0200 Message-ID: <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) To: Paul Vixie Cc: "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Apr 20, 2009 at 6:45 PM, Paul Vixie wrote: >> From: bert hubert >> Well.. Be that as it may, EDNS-PING is an easy upgrade. In fact, it is >> out there today. ... > > this is an easy upgrade for an implementor, or for a single operator. =A0= it > is NOT an easy upgrade for the industry, nor will it be if it happens to > try to occur unplanned/organically. It is out there already on some of the largest nameservers on the planet in terms of zones. In fact, the resolver component has briefly been trialled by a huge incumbent telco. This discovered a small number of interoperability errors, but also discovered that between 1 and 5% of all queries could already be protected by EDNS PING. For my own household, this number is >25%. So I am unsure where you base your claims on that it is not an easy upgrade - almost nobody noticed. We even have the BIND patches ready. So far it appears there is a very small number of servers that misbehave on receiving an EDNS-PING adorned query - mostly F5 load balancers. F5 is already aware of the issue. Bert -- to unsubscribe send a message to namedroppers-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 Apr 20 10:41:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611E33A6A9D; Mon, 20 Apr 2009 10:41:47 -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 7gy6xwcRiMAC; Mon, 20 Apr 2009 10:41:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC04A3A67D4; Mon, 20 Apr 2009 10:41:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvxS0-0001fv-Ue for namedroppers-data0@psg.com; Mon, 20 Apr 2009 17:38:36 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvxRo-0001e8-Qt for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 17:38:30 +0000 Received: from guava.gson.org (a91-152-93-245.elisa-laajakaista.fi [91.152.93.245]) by gurgel.gson.org (Postfix) with ESMTP id 227AE7C8FD; Mon, 20 Apr 2009 17:38:21 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 3549975F46; Mon, 20 Apr 2009 20:38:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18924.45834.624632.624151@guava.gson.org> Date: Mon, 20 Apr 2009 20:38:18 +0300 To: bert hubert Cc: "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> References: <49DB20B8.7020505@cryptocom.ru> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> 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: bert hubert wrote in regard to EDNS PING: > It is out there already on some of the largest nameservers on the > planet in terms of zones. Could you please point us to a working URL for a public specification of the EDNS PING protocol as implemented by these servers? -- 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 Apr 20 11:02:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9493A68CB; Mon, 20 Apr 2009 11:02:16 -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 UjAGk27YB-H1; Mon, 20 Apr 2009 11:02:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9016F3A696F; Mon, 20 Apr 2009 11:02:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvxm1-0003VV-NC for namedroppers-data0@psg.com; Mon, 20 Apr 2009 17:59:17 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvxlf-0003Tw-Qp for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 17:59:10 +0000 Received: by ewy2 with SMTP id 2so1840631ewy.41 for ; Mon, 20 Apr 2009 10:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=G7EcryurZ8x+J6pCu3yDYVRPpaA0fnERREv2Vc7Ltu8=; b=Fq8xOnCvHdQ7QgfPV4igQ+tXGADliRqJIMJN1ymPMEoNSC3ZikdikerFUJ6GOCQQVT 1eQNWiB7KzYNjZQTZ+yWnVL9QjND3mm50hnLPSd01GZ+2uaz3vSM/zpWkZYYl7lMywbK Vetf02r3BDLLfdCjn4NhPBOS5JyfqhW52yURU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=NVVNVkfMIsuEHAY8z8t/QdfAOMD61qcuI9+J3uDyK3+BEk+DtukAZw0bs5rZ3slnHp oR2I3huKVwgdIWklj65DeNknpZq6maRuf0qibsuuP8xdJ6IIprGcFZkZitNvuRrFcACy PIAORZ6IsqQ/50xGTnZG2LhPnHFq0kyu2gOWE= MIME-Version: 1.0 Received: by 10.210.92.8 with SMTP id p8mr4015852ebb.6.1240250334196; Mon, 20 Apr 2009 10:58:54 -0700 (PDT) In-Reply-To: <18924.45834.624632.624151@guava.gson.org> References: <49DB20B8.7020505@cryptocom.ru> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <18924.45834.624632.624151@guava.gson.org> From: bert hubert Date: Mon, 20 Apr 2009 19:58:39 +0200 Message-ID: <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) To: Andreas Gustafsson Cc: "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Apr 20, 2009 at 7:38 PM, Andreas Gustafsson wrote: > bert hubert wrote in regard to EDNS PING: >> It is out there already on some of the largest nameservers on the >> planet in terms of zones. > > Could you please point us to a working URL for a public specification > of the EDNS PING protocol as implemented by these servers? Andreas - of course. The EDNS PING draft only specifies *how* to send an EDNS PING request, and also how to respond to one if you are so inclined. It does not specify when or how one should use such a request. All relevant information is on http://edns-ping.org and specifically http://edns-ping.org/draft The copy of the draft on the IETF servers has sadly expired, I'll upload a new one later today or this week. Kind regards, Bert Hubert -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From jdavis@accredhome.com Mon Apr 20 11:44:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA0E3A6BAC for ; Mon, 20 Apr 2009 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.998 X-Spam-Level: X-Spam-Status: No, score=-12.998 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 lVPSGXpPtwHl for ; Mon, 20 Apr 2009 11:43:59 -0700 (PDT) Received: from advunibyte.de (unknown [88.233.135.124]) by core3.amsl.com (Postfix) with SMTP id 8101F3A6E4A for ; Mon, 20 Apr 2009 11:43:56 -0700 (PDT) To: " Date: Mon, 20 Apr 2009 11:43:56 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Mon Apr 20 12:07:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C023A696F; Mon, 20 Apr 2009 12:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-0.287, 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 1zESuQ-M7poq; Mon, 20 Apr 2009 12:07:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A84B3A63EC; Mon, 20 Apr 2009 12:07:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvyky-000AxL-EE for namedroppers-data0@psg.com; Mon, 20 Apr 2009 19:02:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvykl-000Auo-0T for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 19:02:09 +0000 Received: from [10.31.200.142] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3KJ1xkC023012; Mon, 20 Apr 2009 15:01:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> References: <49DB20B8.7020505@cryptocom.ru> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <18924.45834.624632.624151@guava.gson.org> <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> Date: Mon, 20 Apr 2009 15:00:41 -0400 To: "namedroppers@ops.ietf.org" From: Edward Lewis Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: A few comments. (Looking at the subj: line) - this isn't a request for adoption of EDNS PING? (Quibble and not the reason I am replying, but) I think the web page is misleading when it says "EDNS-PING is currently specified by an IETF draft" because the IETF has not vetted this at all. I would accept that it is "documented" but claiming it's specified - well, okay, this is a quibble, but "specified" makes it sound like this is a vetted concept. My issue with EDNS-PING (section 3.3) is that the "opaque payload" has to be unpredictable (random) or it's like carrying cement blocks in the back of your car for more traction in summer. (I.e., if the payload is always "DNS Rulz" then the attacker doesn't even have to off-net to forge it.) If the payload then requires (some sort of) unpredictability/randomness then there's all that state to maintain (per query), as well as having to generate the payload. This might lead to a notice in the security section that a heavy baseless query load might be there to DoS the recursive service. I'd say all this if the document came into the WG, probably in more detail and certainly more discussion in the event I missed something. Besides the exposed workload on the cache, this just gets you assurance the intended remote end answered your query. You can't tell if the remote end diddled the bits, etc. (Perhaps that's good enough though.) Comparing this to DNSSEC, I don't see a big win. Sure you save the authority side coordination but you lose source authenticity. EDNS-PING does less work for less cost. And I presume that DNSSEC is assumed to be a lot of work in operations (I'm not so sure of that once it gets past the deployment phase). It is cool that this is work which puts the onus on the end points to carry this out, taking the middle boxes of DNS production out of the game. But without the middle boxes (here the registries and authoritative servers) participating, there's no proof that the received data started from the proper location. At 19:58 +0200 4/20/09, bert hubert wrote: >On Mon, Apr 20, 2009 at 7:38 PM, Andreas Gustafsson wrote: >> bert hubert wrote in regard to EDNS PING: >>> It is out there already on some of the largest nameservers on the >>> planet in terms of zones. >> >> Could you please point us to a working URL for a public specification >> of the EDNS PING protocol as implemented by these servers? > >Andreas - of course. The EDNS PING draft only specifies *how* to send >an EDNS PING request, and also how to respond to one if you are so >inclined. > >It does not specify when or how one should use such a request. > >All relevant information is on http://edns-ping.org and specifically >http://edns-ping.org/draft > >The copy of the draft on the IETF servers has sadly expired, I'll >upload a new one later today or this week. > >Kind regards, > >Bert Hubert > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 20 12:09:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5453E3A6FB4; Mon, 20 Apr 2009 12:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.729 X-Spam-Level: X-Spam-Status: No, score=-4.729 tagged_above=-999 required=5 tests=[AWL=-0.234, 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 NYNL5FXKu+MR; Mon, 20 Apr 2009 12:09:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 731E13A69E4; Mon, 20 Apr 2009 12:09:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvyok-000BhH-79 for namedroppers-data0@psg.com; Mon, 20 Apr 2009 19:06:10 +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 1LvyoP-000BeR-HO for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 19:05:55 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n3KJ3g8x031302; Mon, 20 Apr 2009 19:03:42 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n3KJ3gXp031301; Mon, 20 Apr 2009 19:03:42 GMT Date: Mon, 20 Apr 2009 19:03:42 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: bert hubert , "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Message-ID: <20090420190342.GA31247@vacation.karoshi.com.> References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26970.1240245906@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, Apr 20, 2009 at 04:45:06PM +0000, Paul Vixie wrote: > > From: bert hubert > > Date: Mon, 20 Apr 2009 15:58:03 +0200 > > > > Well.. Be that as it may, EDNS-PING is an easy upgrade. In fact, it is > > out there today. ... > > this is an easy upgrade for an implementor, or for a single operator. it > is NOT an easy upgrade for the industry, nor will it be if it happens to > try to occur unplanned/organically. are you advocating centralized planning, a flag day, or are you indicaating that EDNS-PING is doomed? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 20 12:27:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6763A6B6B; Mon, 20 Apr 2009 12:27:14 -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 CN6VtWfIBm2V; Mon, 20 Apr 2009 12:27:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1CB63A67B6; Mon, 20 Apr 2009 12:27:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvz4w-000Dom-5B for namedroppers-data0@psg.com; Mon, 20 Apr 2009 19:22:54 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lvz4A-000Dfm-Nq for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 19:22:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 12C76A101D; Mon, 20 Apr 2009 19:22:06 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: bmanning@vacation.karoshi.com cc: bert hubert , "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: Your message of "Mon, 20 Apr 2009 19:03:42 GMT." <20090420190342.GA31247@vacation.karoshi.com.> References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <20090420190342.GA31247@vacation.karoshi.com.> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 20 Apr 2009 19:22:06 +0000 Message-ID: <34519.1240255326@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > this is an easy upgrade for an implementor, or for a single operator. it > > is NOT an easy upgrade for the industry, nor will it be if it happens to > > try to occur unplanned/organically. > > are you advocating centralized planning, a flag day, or > are you indicaating that EDNS-PING is doomed? neither. -- to unsubscribe send a message to namedroppers-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 Apr 20 12:42:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C8628C0E6; Mon, 20 Apr 2009 12:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=-0.476, 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 ysqI397bM4KT; Mon, 20 Apr 2009 12:42:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECE423A67F4; Mon, 20 Apr 2009 12:42:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvzJU-000F1K-QM for namedroppers-data0@psg.com; Mon, 20 Apr 2009 19:37:56 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LvzJG-000F0U-1P for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 19:37:50 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3KJbbMp017146; Mon, 20 Apr 2009 12:37:37 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org" Message-Id: <1636696B-35CF-43F0-87B5-A6E00F9888DB@icsi.berkeley.edu> From: Nicholas Weaver To: Edward Lewis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Date: Mon, 20 Apr 2009 12:37:37 -0700 References: <49DB20B8.7020505@cryptocom.ru> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <18924.45834.624632.624151@guava.gson.org> <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 20, 2009, at 12:00 PM, Edward Lewis wrote: > If the payload then requires (some sort of) unpredictability/ > randomness then there's all that state to maintain (per query), as > well as having to generate the payload. This might lead to a notice > in the security section that a heavy baseless query load might be > there to DoS the recursive service. I'd say all this if the > document came into the WG, probably in more detail and certainly > more discussion in the event I missed something. The amount of stateholding you are talking about is trivial. Lets assume a truly MASSIVE resolver, handling 1M outstanding queries, and it needs to hold an additional 32B of state per outstanding query. Thats a whopping 32 MB of state. Or, at current market prices, less than $.25 of DRAM. Any recursive resolver which could be DOSed by the stateholding requirements of an EDNS-Ping is broken. -- to unsubscribe send a message to namedroppers-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 Apr 20 13:35:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A034D3A63EC; Mon, 20 Apr 2009 13:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 OdudLMwllu90; Mon, 20 Apr 2009 13:35:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DEEDD3A6833; Mon, 20 Apr 2009 13:35:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw06X-000K3s-7t for namedroppers-data0@psg.com; Mon, 20 Apr 2009 20:28:37 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw06L-000K2L-0f for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 20:28:31 +0000 Received: from [10.31.200.142] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3KKSK34023962; Mon, 20 Apr 2009 16:28:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <1636696B-35CF-43F0-87B5-A6E00F9888DB@icsi.berkeley.edu> References: <49DB20B8.7020505@cryptocom.ru> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <18924.45834.624632.624151@guava.gson.org> <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> <1636696B-35CF-43F0-87B5-A6E00F9888DB@icsi.berkeley.edu> Date: Mon, 20 Apr 2009 16:26:57 -0400 To: "namedroppers@ops.ietf.org" From: Edward Lewis Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 12:37 -0700 4/20/09, Nicholas Weaver wrote: >The amount of stateholding you are talking about is trivial. Memory usage is trivial in context. The bigger issue is that this is just another hop-by-hop security mechanism. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 20 13:37:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589183A6AEE; Mon, 20 Apr 2009 13:37:06 -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 J8EDCw17KI+0; Mon, 20 Apr 2009 13:37:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4BCC73A6833; Mon, 20 Apr 2009 13:35:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw09v-000KLf-E2 for namedroppers-data0@psg.com; Mon, 20 Apr 2009 20:32:07 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw09a-000KJW-Im for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 20:32:01 +0000 Received: by ewy2 with SMTP id 2so1898999ewy.41 for ; Mon, 20 Apr 2009 13:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=PTWpMuIZVt78PCfo5ID9++9ERAdzqqjAINB+PcxThng=; b=g0jZ647nKIpDnZJD+MZM2SCyLRvq7jwHyZ4xZZW3XUgF7DFcT36lfd5dkqI4gigjn4 3kP3nWpcMI13Y9mhIGKC5H0juJZ7+LR9MpuEM1pWgVjBocbgeNf5zMsCqK7nq32hDNwF j6H/KTyF1kWGiVX3kwbqN1tSdBCDqIDD67qLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=DXC6v+4UCe3QCPugEHol5MqP7lcPUoIU0pa/wtN8bD36UbXQdTs/uVUW08AXlPBc+m zSydGqpFubp06IgkyxY7K2VFl41gfn5PI0TTCOR3+5r78QQhTrf9nrPaIfGD6M+yrc8n CLIGdV7vSoX5AOnE5/hnOfJbMVSZH5QO1wGUI= MIME-Version: 1.0 Received: by 10.210.30.1 with SMTP id d1mr4150958ebd.33.1240259505146; Mon, 20 Apr 2009 13:31:45 -0700 (PDT) From: bert hubert Date: Mon, 20 Apr 2009 22:31:30 +0200 Message-ID: <3efd34cc0904201331s32f7882bv95119df436829a03@mail.gmail.com> Subject: [dnsext] Request for adoption of draft-hubert-ulevitch-edns-ping.txt as a working group document To: "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear working group, As part of the continuing forgery resilience effort, as discussed in several meetings, David and I would like to submit the EDNS-PING draft as a working group document. Draft -01 has just been submitted, until it appears, it can also be found on http://edns-ping.org/draft Our feeling is that this draft can further both the current use of DNS, as well as protect any future DNSSEC-enabled network from forgeries which might disrupt operations. As such, the applicability of this draft is broad. We therefore hope you will support draft-hubert-ulevitch-edns-ping.txt as a working group document. Kind regards, Bert Hubert -- to unsubscribe send a message to namedroppers-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 Apr 20 14:00:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D103A6C0B; Mon, 20 Apr 2009 14:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-0.274, 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 UdePpTKGdHnt; Mon, 20 Apr 2009 14:00:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BEDF3A6B13; Mon, 20 Apr 2009 14:00:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw0X8-000MEg-4i for namedroppers-data0@psg.com; Mon, 20 Apr 2009 20:56:06 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw0Wv-000ME1-96 for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 20:55:59 +0000 Received: from [10.31.200.142] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3KKtn9T024451; Mon, 20 Apr 2009 16:55:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0904201331s32f7882bv95119df436829a03@mail.gmail.com> References: <3efd34cc0904201331s32f7882bv95119df436829a03@mail.gmail.com> Date: Mon, 20 Apr 2009 16:54:11 -0400 To: "namedroppers@ops.ietf.org" From: Edward Lewis Subject: Re: [dnsext] Request for adoption of draft-hubert-ulevitch-edns-ping.txt as a working group document Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 22:31 +0200 4/20/09, bert hubert wrote: >Our feeling is that this draft can further both the current use of >DNS, as well as protect any future DNSSEC-enabled network from >forgeries which might disrupt operations. I certainly think this is on-topic for the WG. Yes, we should take this on and have a discussion. I hope we can clear address last calls and other document adoption requests too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 20 17:05:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7823A6FB3; Mon, 20 Apr 2009 17:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=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 81AXr-m5XB-o; Mon, 20 Apr 2009 17:05:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7987A3A6F7C; Mon, 20 Apr 2009 17:05:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw3NJ-000AMc-0m for namedroppers-data0@psg.com; Mon, 20 Apr 2009 23:58:09 +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 1Lw3N6-000ALe-3H for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 23:58:02 +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 n3KNvqS0008646 for ; Mon, 20 Apr 2009 18:57:54 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3KNvPMo010317 for ; Mon, 20 Apr 2009 18:57:52 -0500 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 19:57:35 -0400 Date: Mon, 20 Apr 2009 19:57:34 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@"localhost." To: namedroppers@ops.ietf.org Subject: Re: Request for adoption (was: [dnsext] New draft has been posted) In-Reply-To: <20090413200602.GC24286@shinkuro.com> Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Apr 2009 23:57:36.0213 (UTC) FILETIME=[C7639850:01C9C213] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, 13 Apr 2009, Andrew Sullivan wrote: > This is a request that WG members to express their opinion as to > whether draft-dolmatov-dnsext-gost-dnssec-00.txt should be adopted > as a WG item. I am happy to have this document become a WG item, though I hope we will hold off on making the assignments (=publishing) until we have seen at least two implementations, thus demonstrating that the spec is reasonably complete and the licensing terms reasonable. That us normally the metric for Draft Standard, not Proposed Standard, but this is a pretty small change. We had similar implementation experience when we defined SHA2 DS records (RFC4509), and we will have it for the rsasha256 draft. I strongly support asking the IRTF's CFRG for a review of this work. Like Paul Hoffman, I disagree with Dan Simon's argument that we need a general policy about adding new algorithms. Further comments on the document: First, this is a delightfully complete -00 draft. Good job. I particularly like already having a DNSKEY example. I hope you will add RRSIG and DS examples, too. Because of the strong use of outside references, I am not sure that the wire and presentation format details are adequately specified, but I suspect implementation experience will clear that up. I specifically support the inclusion of the new DS digest algorithm. Perhaps I don't fully understand Olafur's objection to that or why DS digest algorithms should have a higher bar than public key algorithms. I'm happy to be enlightened. There was some complaint about mixing implementation and operational considerations. Section 7.2, at least, is entirely necessary (that's the "NSEC3 is allowed for this algorithm" statement). The recommendation in section 7.1 ("...SHOULD be able to support...GOST...") may be too strong, but I would like to reserve judgement. Please leave it marked as an open issue. The document assigns a new hash algorithm for NSEC3 (for hashing names). This is the first new NSEC3 hash algorithm, so something more is required. Quoting RFC5155: Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm parameter, this document does not define a particular mechanism for safely transitioning from one NSEC3 hash algorithm to another. When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined. Rather than trying to define a transition mechanism, I suggest that the NSEC3 hash algorithm assignment be dropped entirely. Your choice. If you do keep this assignment, it needs to be mentioned in the intro and abstract, which is not currently done. Lastly, edit Section 7.2 to insert "may". Old: RFC5155 [RFC5155] defines new algorithm identifiers for existing signing algorithms, to indicate that zones signed with these algorithm identifiers use NSEC3 instead of NSEC records to provide denial of existence. New: RFC5155 [RFC5155] defines new algorithm identifiers for existing signing algorithms, to indicate that zones signed with these algorithm identifiers may use either NSEC3 or NSEC records to provide denial of existence. -- Samuel Weiler -- to unsubscribe send a message to namedroppers-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 Apr 20 18:17:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA423A6BA4; Mon, 20 Apr 2009 18:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.300, 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 8NB33z4VL6wq; Mon, 20 Apr 2009 18:17:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 364573A6AD8; Mon, 20 Apr 2009 18:17:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw4W3-000Fxz-Ac for namedroppers-data0@psg.com; Tue, 21 Apr 2009 01:11:15 +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 1Lw4Vq-000FxG-F0 for namedroppers@psg.com; Tue, 21 Apr 2009 01:11:08 +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 n3L1B1iG009141; Mon, 20 Apr 2009 20:11:01 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3L1B1af011750; Mon, 20 Apr 2009 20:11:01 -0500 Received: from localhost ([157.185.80.253]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 21:01:04 -0400 Date: Mon, 20 Apr 2009 21:01:01 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@"localhost." To: Paul Hoffman cc: namedroppers@psg.com Subject: Re: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-OriginalArrivalTime: 21 Apr 2009 01:01:04.0650 (UTC) FILETIME=[A564F6A0:01C9C21C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ... the coverage of NSEC3 is contradictory to the point where I > can't figure out what is wanted. ... > a) Mandatory support I don't see the problem with a). > b) Confused MUST > "A DNSSEC validator that implements RSA/SHA-2 MUST be able ... > vs. > "If this is not the case..." I see your point, but I like the clarification in the existing text. I think the existing text is fine. But I'm also OK with the proposed edits. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 21 00:47:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C933A6A98; Tue, 21 Apr 2009 00:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.765 X-Spam-Level: X-Spam-Status: No, score=-105.765 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 3fJlF2bBPHF9; Tue, 21 Apr 2009 00:47:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C4063A6A6D; Tue, 21 Apr 2009 00:47:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwAae-000KFt-5a for namedroppers-data0@psg.com; Tue, 21 Apr 2009 07:40:24 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwAaP-000KEc-Pa for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 07:40:16 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id C4A3B1C0108; Tue, 21 Apr 2009 09:40:08 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id BF9571C00E9; Tue, 21 Apr 2009 09:40:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id BDB0CA1D982; Tue, 21 Apr 2009 09:40:08 +0200 (CEST) Date: Tue, 21 Apr 2009 09:40:08 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: bert hubert , "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Message-ID: <20090421074008.GA11045@nic.fr> References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <28085.1240247221@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28085.1240247221@nsa.vix.com> X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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 Mon, Apr 20, 2009 at 05:07:01PM +0000, Paul Vixie wrote a message of 9 lines which said: > > So I am unsure where you base your claims on that it is not an easy > > upgrade - almost nobody noticed. > > the industry is much larger, in extent and in time, than you're measuring. With this reasoning, DNSSEC is doomed as well, because many middleboxes, firewalls, load balancers, etc, have problems with DNSSEC, 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 Tue Apr 21 00:51:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509293A685D; Tue, 21 Apr 2009 00:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.782 X-Spam-Level: X-Spam-Status: No, score=-105.782 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 eBF+fesL9ltS; Tue, 21 Apr 2009 00:51:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78B5D3A69A4; Tue, 21 Apr 2009 00:51:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwAhB-000Kio-GG for namedroppers-data0@psg.com; Tue, 21 Apr 2009 07:47:09 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwAgy-000Ki9-J6 for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 07:47:03 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id DBE021C0108; Tue, 21 Apr 2009 09:46:55 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D73951C00E9; Tue, 21 Apr 2009 09:46:55 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D4ACB7B0037; Tue, 21 Apr 2009 09:46:55 +0200 (CEST) Date: Tue, 21 Apr 2009 09:46:55 +0200 From: Stephane Bortzmeyer To: Edward Lewis Cc: "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Message-ID: <20090421074655.GB11045@nic.fr> References: <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <18924.45834.624632.624151@guava.gson.org> <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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 Mon, Apr 20, 2009 at 03:00:41PM -0400, Edward Lewis wrote a message of 83 lines which said: > Besides the exposed workload on the cache, this just gets you > assurance the intended remote end answered your query. You can't > tell if the remote end diddled the bits, etc. (Perhaps that's good > enough though.) Well, EDNS-ping protects the channel, not the data. It is not a direct competitor of DNSSEC, rather an extension to RFC 5452. Now, we could discuss for years wether channel protection is better than data protection or vice-versa. I would say we need both: ultimately, DNSSEC rulz and replaces everything but security often requires several defenses combined. -- to unsubscribe send a message to namedroppers-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 Apr 21 02:26:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C283A69A2; Tue, 21 Apr 2009 02:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 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, 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 XLuCRBXm154P; Tue, 21 Apr 2009 02:26:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 829043A68AD; Tue, 21 Apr 2009 02:26:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwCAE-0003XJ-9D for namedroppers-data0@psg.com; Tue, 21 Apr 2009 09:21:14 +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 1LwCA2-0003WI-1C for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 09:21:07 +0000 Message-ID: <49ED8FF9.1020308@ca.afilias.info> Date: Tue, 21 Apr 2009 11:20:57 +0200 From: Shane Kerr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Paul Vixie CC: "namedroppers@ops.ietf.org" Subject: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> In-Reply-To: <70202.1239896047@nsa.vix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul, Paul Vixie wrote: > i think that any effort beyond dns-0x20 to secure against off-path attackers > is misplaced. dns must be secured end to end, which will not only enable a > new class of dnssec-aware applications, but obviate the need to secure dns > hop by hop. I agree somewhat, although there is some room for hop-by-hop work: 1. opening the field up for encrypted DNS queries 2. securing the *last* hop I know #1 was declared out of scope 15 years ago, but that does not mean this cannot be re-visited. There may be some text that gives recommendations on #2, but I'm not familiar with it. Finally, I do think there is room for adopting clever techniques like DNSCurve, even if they "only" secure hop-by-hop. -- 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 Tue Apr 21 02:56:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D423A68FD; Tue, 21 Apr 2009 02:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[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 1nZie-hZP76U; Tue, 21 Apr 2009 02:56:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 755533A6B79; Tue, 21 Apr 2009 02:56:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwCdM-0005th-Ug for namedroppers-data0@psg.com; Tue, 21 Apr 2009 09:51:20 +0000 Received: from [194.100.2.122] (helo=smtp2.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwCd9-0005sM-Vu for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 09:51:14 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp2.tdc.fi (Postfix) with ESMTP id CA5E36A9E96 for ; Tue, 21 Apr 2009 12:51:06 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) Date: Tue, 21 Apr 2009 12:50:52 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) Thread-Index: AcnCZgPOpY0Ia63XSAyEIQQyzqGuAQAAGGVw References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1uYW1lZHJvcHBlcnNA b3BzLmlldGYub3JnIFttYWlsdG86b3duZXItDQo+IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBTaGFuZSBLZXJyDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIxLCAyMDA5 IDEyOjIxIFBNDQo+IFRvOiBQYXVsIFZpeGllDQo+IENjOiBuYW1lZHJvcHBlcnNAb3BzLmlldGYu b3JnDQo+IFN1YmplY3Q6IFNlY3VyaW5nIGhvcCBieSBob3AgKHdhcyBSZTogRUROUyBwaW5nIG1l Y2hhbmlzbXMgKHdhcyBbZG5zZXh0XQ0KPiBSZTogUmVxdWVzdCBmb3IgYWRvcHRpb24pKQ0KPiAN Cj4gUGF1bCwNCj4gDQo+IFBhdWwgVml4aWUgd3JvdGU6DQo+ID4gaSB0aGluayB0aGF0IGFueSBl ZmZvcnQgYmV5b25kIGRucy0weDIwIHRvIHNlY3VyZSBhZ2FpbnN0IG9mZi1wYXRoDQo+IGF0dGFj a2Vycw0KPiA+IGlzIG1pc3BsYWNlZC4gIGRucyBtdXN0IGJlIHNlY3VyZWQgZW5kIHRvIGVuZCwg d2hpY2ggd2lsbCBub3Qgb25seQ0KPiBlbmFibGUgYQ0KPiA+IG5ldyBjbGFzcyBvZiBkbnNzZWMt YXdhcmUgYXBwbGljYXRpb25zLCBidXQgb2J2aWF0ZSB0aGUgbmVlZCB0bw0KPiBzZWN1cmUgZG5z DQo+ID4gaG9wIGJ5IGhvcC4NCj4gDQo+IEkgYWdyZWUgc29tZXdoYXQsIGFsdGhvdWdoIHRoZXJl IGlzIHNvbWUgcm9vbSBmb3IgaG9wLWJ5LWhvcCB3b3JrOg0KPiANCj4gMS4gb3BlbmluZyB0aGUg ZmllbGQgdXAgZm9yIGVuY3J5cHRlZCBETlMgcXVlcmllcw0KPiAyLiBzZWN1cmluZyB0aGUgKmxh c3QqIGhvcA0KPiANCj4gSSBrbm93ICMxIHdhcyBkZWNsYXJlZCBvdXQgb2Ygc2NvcGUgMTUgeWVh cnMgYWdvLCBidXQgdGhhdCBkb2VzIG5vdA0KPiBtZWFuDQo+IHRoaXMgY2Fubm90IGJlIHJlLXZp c2l0ZWQuDQo+IA0KPiBUaGVyZSBtYXkgYmUgc29tZSB0ZXh0IHRoYXQgZ2l2ZXMgcmVjb21tZW5k YXRpb25zIG9uICMyLCBidXQgSSdtIG5vdA0KPiBmYW1pbGlhciB3aXRoIGl0Lg0KPiANCj4gDQo+ IEZpbmFsbHksIEkgZG8gdGhpbmsgdGhlcmUgaXMgcm9vbSBmb3IgYWRvcHRpbmcgY2xldmVyIHRl Y2huaXF1ZXMgbGlrZQ0KPiBETlNDdXJ2ZSwgZXZlbiBpZiB0aGV5ICJvbmx5IiBzZWN1cmUgaG9w LWJ5LWhvcC4NCj4gDQo+IC0tDQo+IFNoYW5lDQo+IA0KDQpJc24ndCBpdCBzdWZmaWNpZW50IHNl Y3VyaXR5IGlmIHlvdSBjYW4gc2VjdXJlIGVhY2ggaG9wIGluIHRoZSBwYXRoPyBJIGtub3cgc2Vj dXJpdHkgaXNuJ3QgdHJhbnNpdGl2ZSByZWxhdGlvbiwgYnV0IGlmIHlvdSBzZWN1cmUgdGhlIGhv cCBhLT5iLT4uLi4tPmVuZCB5b3UgY2FuIGJlIHF1aXRlIGNvbmZpZGVudC4gVGhlIHBhdGggYS0+ ZW5kIGlzbid0IHNlY3VyZSBieSBkZWZpbml0aW9uLCBidXQgSSB0aGluayBpdCBpcyBpbiBwcmFj dGljZS4gDQoNCi0tLQ0KQWtpIFR1b21pDQpUREMgT3kNCg0K -- to unsubscribe send a message to namedroppers-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 Apr 21 03:16:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3703A6AC9; Tue, 21 Apr 2009 03:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.498 X-Spam-Level: X-Spam-Status: No, score=-105.498 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, 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 WyB3GI2dLzQQ; Tue, 21 Apr 2009 03:16:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 400563A6E47; Tue, 21 Apr 2009 03:15:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwCxl-0008N0-Ds for namedroppers-data0@psg.com; Tue, 21 Apr 2009 10:12:25 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwCxX-0008KC-3C for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 10:12:17 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 67DEF1C0106; Tue, 21 Apr 2009 12:12:10 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 635B71C00F5; Tue, 21 Apr 2009 12:12:10 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 60E42A1D9A3; Tue, 21 Apr 2009 12:12:10 +0200 (CEST) Date: Tue, 21 Apr 2009 12:12:10 +0200 From: Stephane Bortzmeyer To: Aki Tuomi Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) Message-ID: <20090421101210.GA29723@nic.fr> References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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, Apr 21, 2009 at 12:50:52PM +0300, Aki Tuomi wrote a message of 47 lines which said: > Isn't it sufficient security if you can secure each hop in the path? No. Counter-example: a recursive name server has been oWn4ed by a cracker. It puts on it a rogue DNS program which modifies responses (for instance, replaces NXDOMAIN by the IP address of an advertisment server). In that case, only end-to-end security protects 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 Tue Apr 21 03:45:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25843A6AD3; Tue, 21 Apr 2009 03:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.727 X-Spam-Level: X-Spam-Status: No, score=0.727 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_32=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 nqInfpemvrEM; Tue, 21 Apr 2009 03:45:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3E1A3A6885; Tue, 21 Apr 2009 03:45:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDO9-000BFB-8i for namedroppers-data0@psg.com; Tue, 21 Apr 2009 10:39:41 +0000 Received: from [74.125.44.29] (helo=yx-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDNx-000BDc-23 for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 10:39:34 +0000 Received: by yx-out-2324.google.com with SMTP id 8so860683yxm.71 for ; Tue, 21 Apr 2009 03:39:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.13.6 with SMTP id 6mr9455379anm.148.1240310367959; Tue, 21 Apr 2009 03:39:27 -0700 (PDT) In-Reply-To: <20090421101210.GA29723@nic.fr> References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> Date: Tue, 21 Apr 2009 03:39:27 -0700 Message-ID: Subject: Re: [dnsext] Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) From: Matthew Dempsky To: Stephane Bortzmeyer Cc: Aki Tuomi , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Apr 21, 2009 at 3:12 AM, Stephane Bortzmeyer wrote: > No. Counter-example: a recursive name server has been oWn4ed by a > cracker. It puts on it a rogue DNS program which modifies responses > (for instance, replaces NXDOMAIN by the IP address of an advertisment > server). In that case, only end-to-end security protects you. How does DNSSEC protect you against this scenario? If the rogue DNS program also strips all DNSSEC records, how does the client know anything is wrong? -- to unsubscribe send a message to namedroppers-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 Apr 21 04:13:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62A73A7001; Tue, 21 Apr 2009 04:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.928 X-Spam-Level: * X-Spam-Status: No, score=1.928 tagged_above=-999 required=5 tests=[AWL=-1.319, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, J_CHICKENPOX_32=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 7vKen4XKc2x7; Tue, 21 Apr 2009 04:13:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1D003A6A65; Tue, 21 Apr 2009 04:13:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDpi-000Ds3-K9 for namedroppers-data0@psg.com; Tue, 21 Apr 2009 11:08:10 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDpW-000DqM-OC for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 11:08:04 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id BBE543EC23; Tue, 21 Apr 2009 15:07:56 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ty9tBeURaedr; Tue, 21 Apr 2009 15:07:56 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 804533EC1F; Tue, 21 Apr 2009 15:07:51 +0400 (MSD) Message-ID: <49EDA907.9060901@cryptocom.ru> Date: Tue, 21 Apr 2009 15:07:51 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Aki Tuomi , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> In-Reply-To: <20090421101210.GA29723@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stephane Bortzmeyer пишет: > >> Isn't it sufficient security if you can secure each hop in the path? > > No. Counter-example: a recursive name server has been oWn4ed by a > cracker. It puts on it a rogue DNS program which modifies responses > (for instance, replaces NXDOMAIN by the IP address of an advertisment > server). In that case, only end-to-end security protects you. > Yes. That depends on the fact whether you trust to _all_ intermediate nodes or not. Hop-by-hop security secures _transport_ between nodes _only_. It does not secure from any erroneous or malicious operation on any intermediate node. dol@ > -- to unsubscribe send a message to namedroppers-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 Apr 21 04:13:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B3C3A7004; Tue, 21 Apr 2009 04:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.093 X-Spam-Level: ** X-Spam-Status: No, score=2.093 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, J_CHICKENPOX_32=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 ZL7Ya3DkN-Ac; Tue, 21 Apr 2009 04:13:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 557813A6A65; Tue, 21 Apr 2009 04:13:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDrr-000E5E-Tp for namedroppers-data0@psg.com; Tue, 21 Apr 2009 11:10:23 +0000 Received: from [87.245.158.60] (helo=mx.cryptocom.ru) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDrd-000E2c-6g for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 11:10:17 +0000 Received: from localhost (localhost [127.0.0.1]) by mx.cryptocom.ru (Postfix) with ESMTP id 6CB173EC23; Tue, 21 Apr 2009 15:10:08 +0400 (MSD) X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Received: from mx.cryptocom.ru ([127.0.0.1]) by localhost (mx.cryptocom.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ib4w6xK-6uFJ; Tue, 21 Apr 2009 15:10:08 +0400 (MSD) Received: from [10.51.22.241] (reedcat.lan.cryptocom.ru [10.51.22.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 3CB4C3EC1F; Tue, 21 Apr 2009 15:10:08 +0400 (MSD) Message-ID: <49EDA98F.6010206@cryptocom.ru> Date: Tue, 21 Apr 2009 15:10:07 +0400 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Matthew Dempsky CC: Stephane Bortzmeyer , Aki Tuomi , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Matthew Dempsky пишет: > On Tue, Apr 21, 2009 at 3:12 AM, Stephane Bortzmeyer wrote: >> No. Counter-example: a recursive name server has been oWn4ed by a >> cracker. It puts on it a rogue DNS program which modifies responses >> (for instance, replaces NXDOMAIN by the IP address of an advertisment >> server). In that case, only end-to-end security protects you. > > How does DNSSEC protect you against this scenario? It does not. If non-DNSSec records are allowed to coexist with DNSSec ones. > If the rogue DNS > program also strips all DNSSEC records, how does the client know > anything is wrong? > By the absence of DNSSec information which was expected to arrive. dol@ -- to unsubscribe send a message to namedroppers-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 Apr 21 04:16:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20C03A6848; Tue, 21 Apr 2009 04:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.161 X-Spam-Level: X-Spam-Status: No, score=0.161 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 GI5SIR+BsQ+d; Tue, 21 Apr 2009 04:16:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC0C23A6A91; Tue, 21 Apr 2009 04:15:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDtu-000EM6-BG for namedroppers-data0@psg.com; Tue, 21 Apr 2009 11:12:30 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDth-000EKz-Si for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 11:12:24 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LwDtM-0007oW-BC; Tue, 21 Apr 2009 13:11:56 +0200 Received: from fweimer by bfk.de with local id 1LwDtd-0005I6-VX; Tue, 21 Apr 2009 13:12:14 +0200 To: Matthew Dempsky Cc: Stephane Bortzmeyer , Aki Tuomi , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Securing hop by hop References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> From: Florian Weimer Date: Tue, 21 Apr 2009 13:12:13 +0200 In-Reply-To: (Matthew Dempsky's message of "Tue, 21 Apr 2009 03:39:27 -0700") Message-ID: <821vrmp8fm.fsf@mid.bfk.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: * Matthew Dempsky: > How does DNSSEC protect you against this scenario? If the rogue DNS > program also strips all DNSSEC records, how does the client know > anything is wrong? If it's validating, it will notice the lack of DNSSEC RRs for the zones for which trust anchors are available. If you strip DNSSEC RRs further down the tree, the validator will see an invalid (BAD/Bogus) signed delegation at some point. (If it's not validating, it will process whatever it receives, of course.) --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Apr 21 04:21:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1711E28C126; Tue, 21 Apr 2009 04:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.502 X-Spam-Level: X-Spam-Status: No, score=-105.502 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, 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 f2ZnDJlHp-FC; Tue, 21 Apr 2009 04:21:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21CE33A68F9; Tue, 21 Apr 2009 04:21:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDzR-000EzS-2Y for namedroppers-data0@psg.com; Tue, 21 Apr 2009 11:18:13 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwDzC-000Exz-PQ for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 11:18:05 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0D4C91C0108; Tue, 21 Apr 2009 13:17:58 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 08D0A1C00E9; Tue, 21 Apr 2009 13:17:58 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 06AECA1D9A3; Tue, 21 Apr 2009 13:17:58 +0200 (CEST) Date: Tue, 21 Apr 2009 13:17:58 +0200 From: Stephane Bortzmeyer To: Matthew Dempsky Cc: Stephane Bortzmeyer , Aki Tuomi , namedroppers@ops.ietf.org Subject: [dnsext] Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) Message-ID: <20090421111758.GA4736@nic.fr> References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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, Apr 21, 2009 at 03:39:27AM -0700, Matthew Dempsky wrote a message of 9 lines which said: > > No. Counter-example: a recursive name server has been oWn4ed by a > > cracker. It puts on it a rogue DNS program which modifies > > responses (for instance, replaces NXDOMAIN by the IP address of an > > advertisment server). In that case, only end-to-end security > > protects you. > > How does DNSSEC protect you against this scenario? You note I was careful not to mention DNSSEC... > If the rogue DNS program also strips all DNSSEC records, how does > the client know anything is wrong? DNSSEC will protect you in that case if the rogue server is not the validating one. So, DNSSEC will detect the cheating in cases like: * the cheater is a rogue secondary authoritative name server for the domain, * there is a validating nameserver on the user's machine, * and in other, more complicated cases (such as several recursors chained). -- to unsubscribe send a message to namedroppers-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 Apr 21 04:29:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E083328C1CA; Tue, 21 Apr 2009 04:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.693 X-Spam-Level: X-Spam-Status: No, score=-3.693 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, 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 iCe0slR1Mw8h; Tue, 21 Apr 2009 04:29:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FEA628C1C7; Tue, 21 Apr 2009 04:29:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwE6m-000FuM-LH for namedroppers-data0@psg.com; Tue, 21 Apr 2009 11:25:48 +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 1LwE6a-000Fsh-DB for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 11:25:42 +0000 Message-ID: <49EDAD28.8020006@ca.afilias.info> Date: Tue, 21 Apr 2009 13:25:28 +0200 From: Shane Kerr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Aki Tuomi CC: namedroppers@ops.ietf.org Subject: Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> In-Reply-To: <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Aki, Aki Tuomi wrote: > The path a->end isn't secure by definition, but I think it is in practice. Is it? :) If a compromised computer is sitting in the same network as a stub resolver, then it can easily send bogus spoofed DNS answers. This may be outside the scope of dnsext and sit in the problem space of securely getting network configuration information to a computer.... -- 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 Tue Apr 21 05:14:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974143A6826; Tue, 21 Apr 2009 05:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[AWL=-1.138, 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 3N0rrLSbYdAu; Tue, 21 Apr 2009 05:14:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9273E3A67E7; Tue, 21 Apr 2009 05:14:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwElb-000K4P-26 for namedroppers-data0@psg.com; Tue, 21 Apr 2009 12:07:59 +0000 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwElO-000K3x-Uw for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 12:07:52 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51510) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1LwElN-0005ug-Pl (Exim 4.70) (return-path ); Tue, 21 Apr 2009 13:07:46 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LwElN-0004v4-VA (Exim 4.67) (return-path ); Tue, 21 Apr 2009 13:07:45 +0100 Date: Tue, 21 Apr 2009 13:07:45 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <18924.45834.624632.624151@guava.gson.org> <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Mon, 20 Apr 2009, Edward Lewis wrote: > > If the payload then requires (some sort of) unpredictability/randomness > then there's all that state to maintain (per query), as well as having > to generate the payload. Can't you create an unpredictable payload using a hash of other query-related data and a secret? I.e. no need for more randomness and no extra state? Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-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 Apr 21 05:22:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4043A6C2F; Tue, 21 Apr 2009 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=3.052, 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 Fgb4CkSQha4B; Tue, 21 Apr 2009 05:22:24 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 9AEF63A6BD6; Tue, 21 Apr 2009 05:22:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwEub-000L9V-WF for namedroppers-data0@psg.com; Tue, 21 Apr 2009 12:17:18 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwEuO-000L8B-Ml for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 12:17:11 +0000 Received: by ewy2 with SMTP id 2so2142905ewy.41 for ; Tue, 21 Apr 2009 05:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=EIonLx7TXsJHLxFgi9VPiJilehvNX2fOb/hMQEu8ppI=; b=t2UEm/v1E+ODnEqSfLdTR2CgoX3gXiRFOaUcSObPJrqekX6+VYAUWQU0Q/jHcpE0Pc LYFbHpTwsPI0o1FdIdcNTTq+HtRCHhqhBps9R8imtrQ6tTksKRZEl2AssiIfWjIu6ch/ APIF69gaEErX1ILa6wyzWqra9nqNW4m5/3S4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=vggBunmxLXGV40/EYamKp3YA0SXpKDmlN873J7uiY1IhgjWbFBKbGHUj5rjZEDoC50 A2WZBlHczbKT2V77eSgvdHloOeL4lNBltAC0igyukxXwgua+l4GaXd+DLKdhhgOLgIE/ LG8PhXe83KZg8qRLro3GKKuhMQPzu6QI1VzBw= MIME-Version: 1.0 Received: by 10.210.71.12 with SMTP id t12mr5989478eba.33.1240316223082; Tue, 21 Apr 2009 05:17:03 -0700 (PDT) In-Reply-To: <821vrmp8fm.fsf@mid.bfk.de> References: <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> <821vrmp8fm.fsf@mid.bfk.de> From: bert hubert Date: Tue, 21 Apr 2009 14:16:48 +0200 Message-ID: <3efd34cc0904210516t399115agcecc1854a8db9a03@mail.gmail.com> Subject: Re: [dnsext] Re: Securing hop by hop To: Florian Weimer Cc: Matthew Dempsky , Stephane Bortzmeyer , Aki Tuomi , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Apr 21, 2009 at 1:12 PM, Florian Weimer wrote: > (If it's not validating, it will process whatever it receives, of > course.) I'm straying outside my field of expertise, but if I understand things correctly, most high query load resolvers will not be in a position to validate everything in realtime (think 20kqps query rates here). This means that any non-validating resolver that wishes to provide robust DNSSEC service had better come with good hop-by-hop protection. Otherwise once the data does hit a validating server, it may well prove bad, with little recourse except to wait for the bogus data to time out from the non-validating resolver. But it is possible that I miss a vital bit of how DNSSEC is supposed to operate. I've trusted the output of 'openssl speed rsa' as an indication how many records sets a validating server might verify per second (around 10000 per cpu). Bert -- to unsubscribe send a message to namedroppers-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 Apr 21 05:22:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBC33A6C2F; Tue, 21 Apr 2009 05:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.41 X-Spam-Level: X-Spam-Status: No, score=-4.41 tagged_above=-999 required=5 tests=[AWL=-1.111, 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 G6SWC1MJXj9i; Tue, 21 Apr 2009 05:22:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E0873A6BFC; Tue, 21 Apr 2009 05:22:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwEvn-000LGu-38 for namedroppers-data0@psg.com; Tue, 21 Apr 2009 12:18:31 +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 1LwEva-000LEw-Ex for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 12:18:24 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:46861) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1LwEvZ-0001K5-Le (Exim 4.70) (return-path ); Tue, 21 Apr 2009 13:18:17 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LwEvZ-0006Sa-MP (Exim 4.67) (return-path ); Tue, 21 Apr 2009 13:18:17 +0100 Date: Tue, 21 Apr 2009 13:18:17 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Shane Kerr cc: namedroppers@ops.ietf.org Subject: Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) In-Reply-To: <49ED8FF9.1020308@ca.afilias.info> Message-ID: References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 21 Apr 2009, Shane Kerr wrote: > > I agree somewhat, although there is some room for hop-by-hop work: > > 1. opening the field up for encrypted DNS queries > 2. securing the *last* hop > > I know #1 was declared out of scope 15 years ago, but that does not mean > this cannot be re-visited. > > There may be some text that gives recommendations on #2, but I'm not > familiar with it. TSIG? Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-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 Apr 21 05:24:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7283A6B32; Tue, 21 Apr 2009 05:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_32=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 UsAkABf-Yqih; Tue, 21 Apr 2009 05:24:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FBF03A6B1C; Tue, 21 Apr 2009 05:24:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwExM-000LQV-F5 for namedroppers-data0@psg.com; Tue, 21 Apr 2009 12:20:08 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwEx1-000LOg-1e for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 12:19:53 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3LCJggY029091; Tue, 21 Apr 2009 05:19:42 -0700 (PDT) Cc: Nicholas Weaver , Aki Tuomi , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Stephane Bortzmeyer In-Reply-To: <20090421101210.GA29723@nic.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption)) Date: Tue, 21 Apr 2009 05:19:43 -0700 References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 21, 2009, at 3:12 AM, Stephane Bortzmeyer wrote: > On Tue, Apr 21, 2009 at 12:50:52PM +0300, > Aki Tuomi wrote > a message of 47 lines which said: > >> Isn't it sufficient security if you can secure each hop in the path? > > No. Counter-example: a recursive name server has been oWn4ed by a > cracker. It puts on it a rogue DNS program which modifies responses > (for instance, replaces NXDOMAIN by the IP address of an advertisment > server). In that case, only end-to-end security protects you. "oWn3ed by your ISP...". The Recursive resolver is the one out-of-path adversary for data traffic that is in-path for DNS traffic. And the only way to handle it is as follows: Do the validation on the stub resolver. ANY validation failures, no matter the cause, including lack of signatures altogether, should instead be fetched directly from the network by the stub resolver, bypassing the recursive resolver completely. But then you have ISPs which block outgoing DNS packets that aren't going to their recursive resolvers! After all, they want to be the ones to sell you the advertisements. And, of course, this means that turning on DNSSEC properly for the end hosts will grossly (and I mean GROSSLY) increase the load on the DNS system for everyone who is not signing their data. (Of course, you can call that a feature...) -- to unsubscribe send a message to namedroppers-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 Apr 21 06:58:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D7F3A6A71; Tue, 21 Apr 2009 06:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 RX3tSbcEK+De; Tue, 21 Apr 2009 06:58:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82D223A6B0A; Tue, 21 Apr 2009 06:58:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGPZ-000649-DX for namedroppers-data0@psg.com; Tue, 21 Apr 2009 13:53:21 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGPF-00060t-5F for namedroppers@psg.com; Tue, 21 Apr 2009 13:53:06 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LwGOt-0003EJ-Az; Tue, 21 Apr 2009 15:52:39 +0200 Received: from fweimer by bfk.de with local id 1LwGPA-0003MA-T8; Tue, 21 Apr 2009 15:52:57 +0200 To: Paul Hoffman Cc: namedroppers@psg.com Subject: Re: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256 References: From: Florian Weimer Date: Tue, 21 Apr 2009 15:52:56 +0200 In-Reply-To: (Paul Hoffman's message of "Mon, 20 Apr 2009 08:57:45 -0700") Message-ID: <82ocuqm7uv.fsf@mid.bfk.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: > A DNSSEC validator that implements RSA/SHA-2 MUST be able to > handle both NSEC and NSEC3 [RFC5155] negative answers. Does "handle" mean that it's okay to treat an NSEC3-protected negative answer as insecure (as opposed to bad)? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Apr 21 07:06:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B673A6BB2; Tue, 21 Apr 2009 07:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[AWL=-0.269, 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 90-dZD5S8PTF; Tue, 21 Apr 2009 07:06:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64DB43A6959; Tue, 21 Apr 2009 07:06:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGXx-000754-JA for namedroppers-data0@psg.com; Tue, 21 Apr 2009 14:02:01 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGXl-00073R-F6 for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 14:01:55 +0000 Received: from [10.31.200.142] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3LE1iAT033425; Tue, 21 Apr 2009 10:01:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DB20B8.7020505@cryptocom.ru> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <18924.45834.624632.624151@guava.gson.org> <3efd34cc0904201058j41bc2502i62a257b7e9e6e08@mail.gmail.com> Date: Tue, 21 Apr 2009 10:00:26 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 13:07 +0100 4/21/09, Tony Finch wrote: >Can't you create an unpredictable payload using a hash of other >query-related data and a secret? I.e. no need for more randomness >and no extra state? Probably (I am not an expert in [mathematical] "randomness.") One of the things that needs to discussed if the document is adopted as a work item. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 21 07:11:31 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5893A6972; Tue, 21 Apr 2009 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 3Shz4BNToB3Y; Tue, 21 Apr 2009 07:11:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 560433A67DB; Tue, 21 Apr 2009 07:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGdw-0007jo-3I for namedroppers-data0@psg.com; Tue, 21 Apr 2009 14:08:12 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGdg-0007hr-FD for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 14:08:04 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LwGdK-0005hQ-Fl; Tue, 21 Apr 2009 16:07:34 +0200 Received: from fweimer by bfk.de with local id 1LwGdc-0005Iq-6z; Tue, 21 Apr 2009 16:07:52 +0200 To: bert hubert Cc: Paul Vixie , "namedroppers@ops.ietf.org" Subject: [dnsext] Re: EDNS ping mechanisms References: <49DB20B8.7020505@cryptocom.ru> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> From: Florian Weimer Date: Tue, 21 Apr 2009 16:07:52 +0200 In-Reply-To: <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> (bert hubert's message of "Mon, 20 Apr 2009 19:04:54 +0200") Message-ID: <82eivmm75z.fsf@mid.bfk.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: * bert hubert: > So far it appears there is a very small number of servers that > misbehave on receiving an EDNS-PING adorned query - mostly F5 load > balancers. F5 is already aware of the issue. Is this with BIND enabled on the box, or with BIND disabled? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Apr 21 07:16:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62E83A6BFA; Tue, 21 Apr 2009 07:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.263, 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 MgpCues93UnF; Tue, 21 Apr 2009 07:16:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52DE13A7020; Tue, 21 Apr 2009 07:16:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGhg-00088n-Ff for namedroppers-data0@psg.com; Tue, 21 Apr 2009 14:12:04 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGhU-00087P-4Z for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 14:11:57 +0000 Received: from [10.31.200.142] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3LEBmiU033554; Tue, 21 Apr 2009 10:11:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <3efd34cc0904210516t399115agcecc1854a8db9a03@mail.gmail.com> References: <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <20090421101210.GA29723@nic.fr> <821vrmp8fm.fsf@mid.bfk.de> <3efd34cc0904210516t399115agcecc1854a8db9a03@mail.gmail.com> Date: Tue, 21 Apr 2009 10:09:18 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Re: Securing hop by hop Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 14:16 +0200 4/21/09, bert hubert wrote: >I'm straying outside my field of expertise, but if I understand things >correctly, most high query load resolvers will not be in a position to >validate everything in realtime (think 20kqps query rates here). This >means that any non-validating resolver that wishes to provide robust >DNSSEC service had better come with good hop-by-hop protection. We should be able to get empirical evidence from ISPs in Sweden on this by now. In theory, a validating server doesn't have to evaluate the entire chain each time new data is received - if the parent keys are already validated (in cache) there may be just one verification to do. This thought might address the concern here but is no match for empirical data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 21 07:23:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05DF3A6BFA; Tue, 21 Apr 2009 07:23:10 -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 hAisU24secmV; Tue, 21 Apr 2009 07:23:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 444B53A67FF; Tue, 21 Apr 2009 07:23:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGmL-0008eE-5W for namedroppers-data0@psg.com; Tue, 21 Apr 2009 14:16:53 +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 1LwGm6-0008cY-OE for namedroppers@psg.com; Tue, 21 Apr 2009 14:16:45 +0000 Received: from [IPv6:2001:7b8:206:1:223:54ff:fe09:d688] ([IPv6:2001:7b8:206:1:223:54ff:fe09:d688]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n3LEGWO2075854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 16:16:33 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <49EDD540.300@NLnetLabs.nl> Date: Tue, 21 Apr 2009 16:16:32 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Florian Weimer CC: Paul Hoffman , namedroppers@psg.com Subject: Re: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256 References: <82ocuqm7uv.fsf@mid.bfk.de> In-Reply-To: <82ocuqm7uv.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 21 Apr 2009 16:16:33 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Florian Weimer wrote: >> A DNSSEC validator that implements RSA/SHA-2 MUST be able to >> handle both NSEC and NSEC3 [RFC5155] negative answers. > > Does "handle" mean that it's okay to treat an NSEC3-protected negative > answer as insecure (as opposed to bad)? > that would mean treating part of a signed zone different than the rest of it... so no. 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: From owner-namedroppers@ops.ietf.org Tue Apr 21 07:33:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A313A6D6E; Tue, 21 Apr 2009 07:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 im7i1fpXqovA; Tue, 21 Apr 2009 07:33:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 69C7B3A6C80; Tue, 21 Apr 2009 07:33:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGxw-000A3z-46 for namedroppers-data0@psg.com; Tue, 21 Apr 2009 14:28:52 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwGxe-000A18-K2 for namedroppers@psg.com; Tue, 21 Apr 2009 14:28:45 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LwGxF-0008Ke-UY; Tue, 21 Apr 2009 16:28:09 +0200 Received: from fweimer by bfk.de with local id 1LwGxX-0001nk-GC; Tue, 21 Apr 2009 16:28:27 +0200 To: Jelte Jansen Cc: Paul Hoffman , namedroppers@psg.com Subject: Re: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256 References: <82ocuqm7uv.fsf@mid.bfk.de> <49EDD540.300@NLnetLabs.nl> From: Florian Weimer Date: Tue, 21 Apr 2009 16:28:27 +0200 In-Reply-To: <49EDD540.300@NLnetLabs.nl> (Jelte Jansen's message of "Tue, 21 Apr 2009 16:16:32 +0200") Message-ID: <828wlum67o.fsf@mid.bfk.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: * Jelte Jansen: > Florian Weimer wrote: >>> A DNSSEC validator that implements RSA/SHA-2 MUST be able to >>> handle both NSEC and NSEC3 [RFC5155] negative answers. >> >> Does "handle" mean that it's okay to treat an NSEC3-protected negative >> answer as insecure (as opposed to bad)? >> > > that would mean treating part of a signed zone different than the rest > of it... so no. Then you should write "validate", I think. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Apr 21 08:44:27 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E34E28C1A5; Tue, 21 Apr 2009 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=-0.908, 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 xafzbKDk5YRG; Tue, 21 Apr 2009 08:44:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C48A28C1A7; Tue, 21 Apr 2009 08:44:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwI57-000J1z-TF for namedroppers-data0@psg.com; Tue, 21 Apr 2009 15:40:21 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwI4u-000J0g-QI for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 15:40:15 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3LFe772034699 for ; Tue, 21 Apr 2009 11:40:07 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n3LFe7f2034698 for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 11:40:07 -0400 (EDT) (envelope-from namedroppers) Received: from [65.122.17.41] (helo=fledge.watson.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw1pF-0002df-NK for namedroppers@ops.ietf.org; Mon, 20 Apr 2009 22:19:00 +0000 Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3KMITGm011046; Mon, 20 Apr 2009 18:18:29 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3KMITEK011043; Mon, 20 Apr 2009 18:18:29 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 20 Apr 2009 18:18:29 -0400 (EDT) From: Samuel Weiler To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] New RRTYPE assignment request: SSLFP RRTYPE Request In-Reply-To: <200904142103.n3EL3AWJ041636@stora.ogud.com> Message-ID: References: <20090413200002.GB24286@shinkuro.com> <873acb6nka.fsf@mid.deneb.enyo.de> <200904142103.n3EL3AWJ041636@stora.ogud.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 20 Apr 2009 23:18:29 +0100 (BST) X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, 14 Apr 2009, Olafur Gudmundsson wrote: > Reusing DNSKEY or DS registries will cause problems. I concur with Olafur's reservations about reusing the DNSKEY and DS hash algorithm registries. I'm not sure what the better replacement is. (Example: do you really want to have multiple numbers assigned for RSA keys, as we presently do in the DNSKEY algorithm registry? Are there bad implications from that? How are you handling the private algorithm numbers? And will you be hitting DNSEXT up for new assignments in that registry when you want to publish a fingerprint for a key whose algorithm has yet to be defined for the purposes of DNSSEC?) Furthermore, some of the details appear underspecified. Ones that seem relevant to this review include: How is the fingerprint calculated and formatted? (There's an implicit answer here, but it's only implicit.) Which one of the eight bits in the mandatory field is relevant? Lastly, the request doesn't capture the distinction between wire and presentation formats. Example: How do you want that 8 bit number to appear in zone files? Also underspecified, though not relevant for this review: What happens if there are two records at the same name? What if one has the madatory bit set and one doesn't? As it is, this template is not ready. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 21 09:40:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D5128C2E4; Tue, 21 Apr 2009 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 HtehyJjnLfd1; Tue, 21 Apr 2009 09:40:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88E4C3A6AEA; Tue, 21 Apr 2009 09:40:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwIwi-000PkR-9H for namedroppers-data0@psg.com; Tue, 21 Apr 2009 16:35:44 +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 1LwIwU-000Pi1-Kp for namedroppers@psg.com; Tue, 21 Apr 2009 16:35:37 +0000 Received: from [10.20.30.163] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LGZLCF064429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 09:35:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <828wlum67o.fsf@mid.bfk.de> References: <82ocuqm7uv.fsf@mid.bfk.de> <49EDD540.300@NLnetLabs.nl> <828wlum67o.fsf@mid.bfk.de> Date: Tue, 21 Apr 2009 09:35:19 -0700 To: Florian Weimer , Jelte Jansen From: Paul Hoffman Subject: Re: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256 Cc: namedroppers@psg.com Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 4:28 PM +0200 4/21/09, Florian Weimer wrote: >* Jelte Jansen: > >> Florian Weimer wrote: >>>> A DNSSEC validator that implements RSA/SHA-2 MUST be able to >>>> handle both NSEC and NSEC3 [RFC5155] negative answers. >>> >>> Does "handle" mean that it's okay to treat an NSEC3-protected negative >>> answer as insecure (as opposed to bad)? >>> >> >> that would mean treating part of a signed zone different than the rest >> of it... so no. > >Then you should write "validate", I think. That works for me. --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 Apr 21 11:28:20 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6803A6E3C; Tue, 21 Apr 2009 11:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 hcWZ2+sBiwmJ; Tue, 21 Apr 2009 11:28:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2B65F3A6E14; Tue, 21 Apr 2009 11:28:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwKcc-000Bof-Ow for namedroppers-data0@psg.com; Tue, 21 Apr 2009 18:23:06 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwKcO-000BnP-Uy for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 18:22:59 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 20BBBA1018 for ; Tue, 21 Apr 2009 18:22:47 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-Reply-To: Your message of "Tue, 21 Apr 2009 09:40:08 +0200." <20090421074008.GA11045@nic.fr> References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <28085.1240247221@nsa.vix.com> <20090421074008.GA11045@nic.fr> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Tue, 21 Apr 2009 18:22:47 +0000 Message-ID: <95007.1240338167@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > > > So I am unsure where you base your claims on that it is not an easy > > > upgrade - almost nobody noticed. > > > > the industry is much larger, in extent and in time, than you're > > measuring. > > With this reasoning, DNSSEC is doomed as well, because many middleboxes, > firewalls, load balancers, etc, have problems with DNSSEC, too. i'm not predicting doom. i'm saying that "boots in lab" or even "deployed it on my nameserver and nobody noticed" are not predictors of success. to really make something like EDNS-PING work we'd have to come up with OPT2 or some super-EDNS signalling that did not have normal DNS as its fallback. i am also *quite* concerned about the extra requests that will be received by nonconforming servers. i defined dns-0x20 this way, but i claimed it was safe since almost all name servers happen to preserve the 0x20 bits today, and the number of duplicated requests is expected to start out very low. in PING, that number is expected to start out very high, and may never approach low. we're talking about hundreds of millions of DNS endpoints, many of whom are never upgraded, only replaced after long lives, or existing perpetually. to the extent that additional hop-by-hop security is needed, dns-0x20 is a better model for it than PING. but i'm not convinced that more hop-by-hop is needed, since the real problems in DNS security include on-path attacks, and there will be a continuing real need for end-to-end no matter what we do hop-by-hop. (that's why i havn't pushed very hard on dns-0x20, btw.) -- to unsubscribe send a message to namedroppers-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 Apr 21 11:59:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D5B28C2D3; Tue, 21 Apr 2009 11:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.322 X-Spam-Level: X-Spam-Status: No, score=-5.322 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 jOjjj5rTG9Tf; Tue, 21 Apr 2009 11:59:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2855228C2AF; Tue, 21 Apr 2009 11:59:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwL8J-000Fjv-S0 for namedroppers-data0@psg.com; Tue, 21 Apr 2009 18:55:51 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwL82-000FiY-QG for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 18:55:45 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3LItVGo020032; Tue, 21 Apr 2009 11:55:31 -0700 (PDT) Cc: Nicholas Weaver , "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Message-Id: <6B37D6E3-BFFC-438C-AADD-B9C88DDBB4B8@icsi.berkeley.edu> From: Nicholas Weaver To: Paul Vixie In-Reply-To: <95007.1240338167@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) Date: Tue, 21 Apr 2009 11:55:31 -0700 References: <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <28085.1240247221@nsa.vix.com> <20090421074008.GA11045@nic.fr> <95007.1240338167@nsa.vix.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 21, 2009, at 11:22 AM, Paul Vixie wrote: > i am also *quite* concerned about the extra requests that will be > received > by nonconforming servers. i defined dns-0x20 this way, but i > claimed it was > safe since almost all name servers happen to preserve the 0x20 bits > today, > and the number of duplicated requests is expected to start out very > low. in > PING, that number is expected to start out very high, and may never > approach > low. we're talking about hundreds of millions of DNS endpoints, > many of whom > are never upgraded, only replaced after long lives, or existing > perpetually. But how many such endpoints are ALSO running at at least 33% of total maximum load? Or return highly volatile results? Thats the thing with extra requests which come from the recursive resolvers: For non-volatile names, its a bounded 3x overhead, which is only a concern if the authority is running at significant load. I think there is too much care given for "load on installed base that won't/can't upgrade". -- to unsubscribe send a message to namedroppers-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 Apr 21 13:03:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105193A6E80; Tue, 21 Apr 2009 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 CmYmQoztSpE8; Tue, 21 Apr 2009 13:03:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 142D53A6E6C; Tue, 21 Apr 2009 13:03:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwM7z-000Nk8-S4 for namedroppers-data0@psg.com; Tue, 21 Apr 2009 19:59:35 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwM7m-000NhG-BQ for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 19:59:28 +0000 Received: by ewy2 with SMTP id 2so2358328ewy.41 for ; Tue, 21 Apr 2009 12:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=U9rJ3+rfgyDrh3RE3dJ59K/qYJzxYEn4kTlyDvCqwQo=; b=A8z9Ke6hpziFI4vUiwTkNrBfLluL7STo8GXTy3dRoh7wozVE9EwPeOPaJuUNuwXuMd 3fV01mCd92a/dpzgWDFQDI6qsRr1x5yudildt27VEt0Y9kK0PjNYoMD8ibt+PXvg12/Y 8nkru0rvaEaX+AOp5Nqbu+fV6GWBjmwohOk6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=lR9SUelcMrQn44k7kT0WUfkLRy45RHBh/ADRNKYr7T6bVcZjWZtQvBovpDGzyzRV48 EZ4lsxsN6e3AmHlK6uKIONqrxX8+/dNbJgS0uKIGBDdxpaQaRirA516S/wYfMK30rhDe mlxMpko5NZBJjXj6t1rnK+6uCFxIoqBVloVzc= MIME-Version: 1.0 Received: by 10.210.51.18 with SMTP id y18mr6472902eby.36.1240343961120; Tue, 21 Apr 2009 12:59:21 -0700 (PDT) In-Reply-To: <95007.1240338167@nsa.vix.com> References: <49E70058.75AA073B@ix.netcom.com> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <3efd34cc0904200658u5894c5bemf37060949f0babdc@mail.gmail.com> <26970.1240245906@nsa.vix.com> <3efd34cc0904201004h6aa60bbdm323572f693dbc91b@mail.gmail.com> <28085.1240247221@nsa.vix.com> <20090421074008.GA11045@nic.fr> <95007.1240338167@nsa.vix.com> From: bert hubert Date: Tue, 21 Apr 2009 21:59:06 +0200 Message-ID: <3efd34cc0904211259o2e6b21f7secdefbe1739baf8a@mail.gmail.com> Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) To: Paul Vixie Cc: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Tue, Apr 21, 2009 at 8:22 PM, Paul Vixie wrote: > i'm not predicting doom. =A0i'm saying that "boots in lab" or even "deplo= yed > it on my nameserver and nobody noticed" are not predictors of success. = =A0to So what is? Also - "deployed it on my nameserver and nobody noticed" has a far different ring to it than "some of the largest nameservers in operation already offer it". Or that millions of people have happily been served by EDNS PING and that only a limited number of problems have been reported, many of which are already in the process of being addressed. The beauty of EDNS PING is that it is so limited, and puts so little demand on anybody. > really make something like EDNS-PING work we'd have to come up with OPT2 = or > some super-EDNS signalling that did not have normal DNS as its fallback. There are lots of other ways to prevent downgrade attacks than to invent whole new protocols. > i am also *quite* concerned about the extra requests that will be receive= d > by nonconforming servers. =A0i defined dns-0x20 this way, but i claimed i= t was What extra requests? You might get one extra request per hour or so to determine if your support for EDNS options has changed. Also, EDNS PING only defines a tool which can be used to enhance forgery resilience. The draft does not tell you to send three extra queries or whatever. EDNS has been out there for ages, as has your fine RFC describing it. If people haven't learned to support it by now, they'll never will. The EDNS RFC is quite clear that implementations must ignore unknown EDNS options. > to the extent that additional hop-by-hop security is needed, dns-0x20 is = a > better model for it than PING. =A0but i'm not convinced that more hop-by-= hop Sure you've been paying attention? dns-0x20 does nothing for . queries, nor does it do very much for TLD queries.. Bert -- to unsubscribe send a message to namedroppers-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 Apr 21 15:49:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17713A7028; Tue, 21 Apr 2009 15:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.94 X-Spam-Level: X-Spam-Status: No, score=-104.94 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 foBspv3nLimw; Tue, 21 Apr 2009 15:49:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81F733A6F00; Tue, 21 Apr 2009 15:49:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwOiC-000EnF-Gu for namedroppers-data0@psg.com; Tue, 21 Apr 2009 22:45:08 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwOhv-000EmX-Oq for namedroppers@ops.ietf.org; Tue, 21 Apr 2009 22:45:01 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 20C5060CF310 for ; Tue, 21 Apr 2009 15:44:51 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Brightmail Gateway) with ESMTP id 080752807E for ; Tue, 21 Apr 2009 15:44:51 -0700 (PDT) X-AuditID: 11807130-a788fbb000000fcd-b4-49ee4c626e71 Received: from [17.206.42.11] (chesh1.apple.com [17.206.42.11]) by relay11.apple.com (Apple SCV relay) with ESMTP id D6F6628080 for ; Tue, 21 Apr 2009 15:44:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: <4DB6B5E1-B18C-4812-8D4F-220120BFB96C@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF DNSEXT WG From: Stuart Cheshire Subject: [dnsext] NSEC for preemptive assertion of nonexistence Date: Tue, 21 Apr 2009 15:44:32 -0700 X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In our discussions last September, Wouter Wijngaards made this good suggestion: > Why don't you use the existing NSEC record type, that can be used to > list all the types present (and absent) for a record? > > It would look like this: > stuartsprinter.local. 120 IN A 169.254.123.45 > stuartsprinter.local. 120 IN NSEC . A NSEC We're finally at the point of implementing this, and we're debating what name should go in the "Next Domain Name" field. The two obvious candidates are root and self, but both have drawbacks: 1. Use root, e.g. "stuartsprinter.local. 120 IN NSEC . A NSEC" + Nice and compact - Introduces a special interpretation for "Next Domain Name" == "root", namely that this is not asserting the non-existence of any other names. Unfortunately, "Next Domain Name" == "root" already has a valid interpretation, namely that this is the last name in the root zone. When the root zone is signed, (if I understand it correctly) the last name in the zone will have an NSEC record something like this: "zw. 2D IN NSEC . NS NSEC". This is asserting that "zw." is the last name in the root zone. 2. Use own rrname, e.g. "stuartsprinter.local. 120 IN NSEC stuartsprinter.local. A NSEC" - Less compact (unless name compression is used, which would violate RFC 3845) + Seems semantically cleaner (but maybe not) This would seem semantically cleaner, except it may still not be quite right. In a signed zone that contains nothing but a single name at its apex, you'd have a self-referential NSEC record, something like this: "minimal-zone.example. 2D IN NSEC minimal-zone.example. A NS SOA NSEC". This is asserting that there are no (delegated or non- delegated) subdomains of "minimal-zone.example." In our mDNS case, this is more than we want to assert, since claiming ownership of "foo.local." does not necessarily assert ownership of "bar.foo.local." or any other names falling under "foo.local." However, I may not be understanding this quite right. In the parent zone ("example.") there will also be an NSEC record, potentially something like this: "minimal-zone.example. 2D IN NSEC next- name.example. NS NSEC". That NSEC record is *not* asserting that the name a.minimal-zone.example. does not exist, just that it does not exist in the "example." zone. I'm trying to work out solution that fits this set of constraints. Given that no perfect solution seems to exist, I'm leaning towards a new option 3: 3. A "special" variant of NSEC, e.g. "stuartsprinter.local. 120 IN NSEC . A" This uses the root domain name as the Next Domain Name field, which is compact on the wire, and simple to program. However, since in this usage case this is a synthesized record, not an actual record in a signed zone, the NSEC bit is *not* set in the bitmap. This means that this special synthesized variant of NSEC is easily distinguishable from the NSEC record that asserts "this is the last record of the root zone" because that record has the NSEC bit set, and the synthesized NSEC that's only talking about one specific name, not a range of names, does not have the NSEC bit set. That's the best I can think of right now. If feels a bit rough, but maybe it's not so bad. It's programmatically simple, and should there ever be any confusion in the future between real NSEC records and these synthetic ones, the absence of the NSEC bit in the synthetic ones means they can be programmatically distinguished. Any better ideas would be welcomed. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.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 Apr 21 18:59:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0253A6A2A; Tue, 21 Apr 2009 18:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[AWL=0.864, 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 tEHUIHrAr2dw; Tue, 21 Apr 2009 18:59:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FC703A68C2; Tue, 21 Apr 2009 18:59:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwReT-0003p1-Vi for namedroppers-data0@psg.com; Wed, 22 Apr 2009 01:53:29 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwRe7-0003mr-Ke for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 01:53:23 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=C5dBesmLDdaltWBDh1jKDs6sil061LpO+G/QYl0fJr5KwYFa073qk/hEvWI82aqM; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.102.235] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LwRe2-0005Pw-J7; Tue, 21 Apr 2009 21:53:04 -0400 Message-ID: <49EE7872.4006954B@ix.netcom.com> Date: Tue, 21 Apr 2009 18:52:50 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shane Kerr CC: Aki Tuomi , namedroppers@ops.ietf.org, DOC/NTIA ICANN Rep , GAC Rep Subject: Re: Securing hop by hop (was Re: EDNS ping mechanisms (was [dnsext]Re: Request for adoption)) References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <4C051246-C56F-4F53-9E9C-8AE662857133@icsi.berkeley.edu> <70202.1239896047@nsa.vix.com> <49ED8FF9.1020308@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B2B@fi-hel2ex01.nordiclan.net> <49EDAD28.8020006@ca.afilias.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688949b9c2cf67e78cde3fcf66c288d7312350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.102.235 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Shane and all, Yes what you suggest is of course true and accurate. I have noticed and documented such activity from Afilias and Nuestar/Nuelevel on too many occasions I care to elaborate on. Spoofing valid keys for DNSSEC is also not all that difficult to accomplish using this sort of approach either, and should be expected and security folks need to be prepared to deal with effectively, appropriately and immediately. Some governments will be hi value targets for such occurrences... I suppose we all will find out early on how successful public service groups within various governments and the private sector that are third parties to such government organizations, their ability to deal effectively, appropriately, and immediately with such eventual breaches and/or compromises of private data. Shane Kerr wrote: > Aki, > > Aki Tuomi wrote: > > The path a->end isn't secure by definition, but I think it is in practice. > > Is it? :) > > If a compromised computer is sitting in the same network as a stub > resolver, then it can easily send bogus spoofed DNS answers. > > This may be outside the scope of dnsext and sit in the problem space of > securely getting network configuration information to a computer.... > > -- > 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: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From pwild@imaxvictoria.com Tue Apr 21 23:35:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D091F3A681E; Tue, 21 Apr 2009 23:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.176 X-Spam-Level: X-Spam-Status: No, score=-39.176 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_SBL=20, 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 a9nl-AwUeoGU; Tue, 21 Apr 2009 23:35:34 -0700 (PDT) Received: from c-68-62-238-245.hsd1.fl.comcast.net (c-68-62-238-245.hsd1.fl.comcast.net [68.62.238.245]) by core3.amsl.com (Postfix) with SMTP id A0DEC3A6D57; Tue, 21 Apr 2009 23:35:32 -0700 (PDT) From: "Claire Drew" To: <"disman-bounces@ietf.org, disman-owner@ietf.org, disman-request@ietf.org, dix@ietf.org, dix-request@ietf.org, dnsext-archive@ietf.org, dnsind-archive"@ietf.org> Subject: Rep will save you thousands Date: Wed, 22 Apr 2009 02:36:51 -0500 Message-ID: <4445ttc784635GNQBdisman-bounces@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit There's no time like the present, and isn't it time you got yourself a beautiful designer watch? http://www.gurixalap.cn So, come visit Diam0nd Reps, the famous watch-portal where thousands of satisfied customers have already found that superb imitation time piece for just a few hundred dollars. http://www.gurixalap.cn Only Diam0nd Reps offers you unsurpassed quality and award-winning customer service. So, what are you waiting for? From owner-namedroppers@ops.ietf.org Wed Apr 22 01:53:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA6F3A6EC9; Wed, 22 Apr 2009 01:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_47=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 NQ5T+y-hiczl; Wed, 22 Apr 2009 01:53:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85B563A6B40; Wed, 22 Apr 2009 01:53:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwY7F-0009br-Sy for namedroppers-data0@psg.com; Wed, 22 Apr 2009 08:47:37 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwY6v-0009a7-Py for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 08:47:30 +0000 Received: by ewy2 with SMTP id 2so2564102ewy.41 for ; Wed, 22 Apr 2009 01:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=IhGr6OYzoSsMhfl3HeG88mHPMHbnc79k04MhfnW7ZR0=; b=rWA1f9hYzHBXc1AMgh0tpEAYi3VOhWcLRYi+h7Ec7J9C1BI+iGHziQVo31gAJGzv0N LyHYYzyhZxNh59BfgnGDKNkZPwZwB2zq48RsiM3E1nfKxuGZRUg9D2pyg5/r4vMhkps9 NMLBL29dPPs+ubzOAg7oHT/GQaaunGDvhsknc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=OfBwZDYzr8VfHMnBkHGljBBinYEgi9yl/amiAaOybj148bSB9xzF3+FQIMtFWCNUjR 6J757hqpITBXLxK+5nQz4ClENBO2iEk/Ejw4a4s9+6T8lMdljmkgrTtXmV7OsM4Y+Udj IGU11YYVPowP8yaPamSUp+gyXNPDxBNGPtkhk= Received: by 10.210.35.5 with SMTP id i5mr6000053ebi.31.1240390036400; Wed, 22 Apr 2009 01:47:16 -0700 (PDT) Received: from ?192.168.1.204? ([193.82.161.205]) by mx.google.com with ESMTPS id 8sm10613681ewy.37.2009.04.22.01.47.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 01:47:15 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: From: John Dickinson To: Stuart Cheshire In-Reply-To: <4DB6B5E1-B18C-4812-8D4F-220120BFB96C@apple.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] NSEC for preemptive assertion of nonexistence Date: Wed, 22 Apr 2009 09:47:13 +0100 References: <4DB6B5E1-B18C-4812-8D4F-220120BFB96C@apple.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 21 Apr 2009, at 23:44, Stuart Cheshire wrote: > In our discussions last September, Wouter Wijngaards made this good > suggestion: > >> Why don't you use the existing NSEC record type, that can be used to >> list all the types present (and absent) for a record? >> >> It would look like this: >> stuartsprinter.local. 120 IN A 169.254.123.45 >> stuartsprinter.local. 120 IN NSEC . A NSEC > > > We're finally at the point of implementing this, and we're debating > what name should go in the "Next Domain Name" field. > > The two obvious candidates are root and self, but both have drawbacks: > > 1. Use root, e.g. "stuartsprinter.local. 120 IN NSEC . A NSEC" > > + Nice and compact > - Introduces a special interpretation for "Next Domain Name" == > "root", namely that this is not asserting the non-existence of any > other names. > > Unfortunately, "Next Domain Name" == "root" already has a valid > interpretation, namely that this is the last name in the root zone. > When the root zone is signed, (if I understand it correctly) the > last name in the zone will have an NSEC record something like this: > "zw. 2D IN NSEC . NS NSEC". This is asserting that "zw." is the last > name in the root zone. > > 2. Use own rrname, e.g. "stuartsprinter.local. 120 IN NSEC > stuartsprinter.local. A NSEC" > > - Less compact (unless name compression is used, which would violate > RFC 3845) > + Seems semantically cleaner (but maybe not) > > This would seem semantically cleaner, except it may still not be > quite right. In a signed zone that contains nothing but a single > name at its apex, you'd have a self-referential NSEC record, > something like this: "minimal-zone.example. 2D IN NSEC minimal- > zone.example. A NS SOA NSEC". This is asserting that there are no > (delegated or non-delegated) subdomains of "minimal-zone.example." > In our mDNS case, this is more than we want to assert, since > claiming ownership of "foo.local." does not necessarily assert > ownership of "bar.foo.local." or any other names falling under > "foo.local." > > However, I may not be understanding this quite right. In the parent > zone ("example.") there will also be an NSEC record, potentially > something like this: "minimal-zone.example. 2D IN NSEC next- > name.example. NS NSEC". That NSEC record is *not* asserting that the > name a.minimal-zone.example. does not exist, just that it does not > exist in the "example." zone. > > I'm trying to work out solution that fits this set of constraints. > Given that no perfect solution seems to exist, I'm leaning towards a > new option 3: > > 3. A "special" variant of NSEC, e.g. "stuartsprinter.local. 120 IN > NSEC . A" > > This uses the root domain name as the Next Domain Name field, which > is compact on the wire, and simple to program. However, since in > this usage case this is a synthesized record, not an actual record > in a signed zone, the NSEC bit is *not* set in the bitmap. This > means that this special synthesized variant of NSEC is easily > distinguishable from the NSEC record that asserts "this is the last > record of the root zone" because that record has the NSEC bit set, > and the synthesized NSEC that's only talking about one specific > name, not a range of names, does not have the NSEC bit set. > > That's the best I can think of right now. If feels a bit rough, but > maybe it's not so bad. It's programmatically simple, and should > there ever be any confusion in the future between real NSEC records > and these synthetic ones, the absence of the NSEC bit in the > synthetic ones means they can be programmatically distinguished. > > Any better ideas would be welcomed. Could another option be to use the successor part of RFC4471? John --- John Dickinson http://www.jadickinson.co.uk I am riding from Lands end to John O'Groats to raise money for Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009 -- to unsubscribe send a message to namedroppers-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 Apr 22 08:14:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC063A6F29; Wed, 22 Apr 2009 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 2Q27pUDotdcq; Wed, 22 Apr 2009 08:14:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B5703A6CE0; Wed, 22 Apr 2009 08:14:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwe2t-000FD2-Ek for namedroppers-data0@psg.com; Wed, 22 Apr 2009 15:07:31 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwe2g-000FBh-3T for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 15:07:24 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3MF7G6J047453 for ; Wed, 22 Apr 2009 11:07:16 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904221507.n3MF7G6J047453@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Apr 2009 11:07:09 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: The WG has received a request to adopt this as a work item. See draft: http://www.ietf.org/internet-drafts/draft-hubert-ulevitch-edns-ping-01.txt The current document falls under the "further Forgery Resilience" clause in our charter. If we are going to debate the merits of this proposal, the chairs think it is going to beneficial to all that we have a common understanding of what the proposal is about and its implications. Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ? Q1.5: Is the cost of Ping caused by it being the first/second option to be standardized or will we have to suffer the same cost when options are added in the future ? Q2: Does ENDS0 Ping offer additional protection to "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSSEC" ? Q3: Are the benefits of ENDS0 Ping realized incrementally with deployment or only when the majority of code bases are deployed? Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or the producer? Q4: Will ENDS0 Ping delay/prevent DNSSEC deployment? (explain) Q5: Does ENDS0 Ping expose any new security risks? Q6: Do you support that the WG adopt the document ? If your answer is NO is there any other mechanism you want considered ? Yes assumes you are willing to review future versions of the document. Note: We have not asked any questions on the details on how the option is implemented as that can be addressed after a consensus on that EDNS0 is beneficial has been reached. Note: Just like EDNS0 discovery is unreliable when dealing with any cast clusters, EDNS Ping discovery will be unreliable during time it takes to upgrade the whole cluster in all locations. This on its own is not an acceptable argument against this particular proposal. Olafur for the chairs [1] Implementation costs, State discovery, State Maintenance, deployment cost, operational cost etc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 22 08:54:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E143628C595; Wed, 22 Apr 2009 08:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=-0.832, 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 6SbmYYeCSG+L; Wed, 22 Apr 2009 08:54:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 298A528C591; Wed, 22 Apr 2009 08:54:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LweiV-000Isn-FV for namedroppers-data0@psg.com; Wed, 22 Apr 2009 15:50:31 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LweiI-000IrR-RP for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 15:50:25 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3MFoG9F047980 for ; Wed, 22 Apr 2009 11:50:17 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904221550.n3MFoG9F047980@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Apr 2009 11:49:42 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: [dnsext] Fwd: [Cfrg] DNSSEC considering adopting GOST R 34.10-2001 and GOST R 34.11-94 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: As WG chair I have followed up on the suggestion that we ask crypto experts for their opinion on the GOST algorithms. see: http://www.irtf.org/mail-archive/web/cfrg/current/msg02612.html I will summarize the results. 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 Wed Apr 22 09:15:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DFA28C5B0; Wed, 22 Apr 2009 09:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.309 X-Spam-Level: X-Spam-Status: No, score=-5.309 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 WMk3fOJfCYWS; Wed, 22 Apr 2009 09:15:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31F7228C250; Wed, 22 Apr 2009 09:15:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwf0k-000Ktm-A5 for namedroppers-data0@psg.com; Wed, 22 Apr 2009 16:09:22 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwf0X-000Ks4-B8 for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 16:09:15 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3MG8Yio028810; Wed, 22 Apr 2009 09:08:34 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_/DNSEXT__chair?= In-Reply-To: <200904221507.n3MF7G6J047453@stora.ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Wed, 22 Apr 2009 09:08:34 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 22, 2009, at 8:07 AM, =D3lafur Gu=F0mundsson /DNSEXT chair wrote: > > > > Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ? Not when implemented on the authority side as well as resolver side: =20= The state management is trivial for both resolver and authority, the =20 packet size amplification is almost trivial, deployment cost is no =20 worse than any other DNS server patch for server operators and its a =20 very minor change for DNS server code implementers.. When not implemented on the authority side: It depends on the =20 fallback mode employed when EDNS0 ping data is not replied to, and =20 this is a cost imposed on those NOT updating to support EDNS0-ping. =20 Such a cost would only be apparent when a significant number of =20 resolvers start using EDNS0-ping. > Q1.5: Is the cost of Ping caused by it being the first/second option =20= > to be > standardized or will we have to suffer the same cost when =20 > options are > added in the future ? > > > Q2: Does ENDS0 Ping offer additional protection to > "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSSEC" ? "Non-DNSSEC DNS": for DNSSEC, EDNS0 ping adds no confidence: it is targeted against out-=20= of-path adversaries, while DNSSEC is targeted against both in-path and =20= out-of-path adversaries. Under an "attack", an EDNS0-Ping failure but DNSSEC success is still a =20= DNSSEC success, and can be trusted if DNSSEC can be trusted. While a DNSSEC failure but EDNS0-Ping success has no impact on =20 security if your threat model is an in-path adversary, because an in-=20 path adversary can always correctly forge the EDNS0-packet. > Q3: Are the benefits of ENDS0 Ping realized incrementally with =20 > deployment or > only when the majority of code bases are deployed? It depends on default behavior and fallback policy. If there is a duplication-based fallback policy for resolvers, =20 resolvers can immediately and directly benefit upon upgrading, AND =20 provide an incentive for authorities to upgrade. If most authorities already echo back the EDNS0-ping payload as a =20 "Don't know, don't care" default behavior, then the benefits for =20 resolvers using EDNS0-ping can be achieved incrementally. If there is no fallback-policy for EDNS0-ping not acknowledged AND =20 most authorities do not currently reply, then the benefits are only =20 achieved when a majority of the authorities will echo back the EDNS0-=20 ping payload. > Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or =20 > the producer? Consumer. > Q4: Will ENDS0 Ping delay/prevent DNSSEC deployment? (explain) If DNSSEC advocates are honest? No. DNSSEC's biggest advantage to creating end-to-end secure applications =20= is to secure Name->Key mappings. EDNS0 Ping does nothing to secure =20 Name->key mappings in any meaningful manner. If DNSSEC advocates are dishonest? Yes. There is a non-trivial group of DNSSEC advocates who view attempts to =20= secure DNS against out-of-path adversaries as weakening the case for =20 DNSSEC deployment, because securing DNS for Name->Address mappings =20 against in-path adversaries does not have a clear system security =20 benefit (with the notable exception of securing against misbehaving =20 recursive resolvers.) These advocates may be correct: Having ordinary DNS perceived as =20 "completely insecure" is a good incentive for DNSSEC deployment. > Q5: Does ENDS0 Ping expose any new security risks? > > Q6: Do you support that the WG adopt the document ? > If your answer is NO is there any other mechanism you want =20 > considered ? > Yes assumes you are willing to review future versions of the document. Yes. I believe there is some supporting survey data that should be =20 conducted (I have already corresponded with Bob Herbert on some =20 suggestions), and I believe that fallback mechanisms should actually =20 be discussed in the draft (not currently present). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From kim@alta247.com Wed Apr 22 10:28:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3293A6D68 for ; Wed, 22 Apr 2009 10:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.685 X-Spam-Level: X-Spam-Status: No, score=-14.685 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 qgCWVf7DfIzo for ; Wed, 22 Apr 2009 10:28:46 -0700 (PDT) Received: from ppp-77-27.20-151.libero.it (ppp-172-30.20-151.libero.it [151.20.30.172]) by core3.amsl.com (Postfix) with SMTP id B66F83A687F for ; Wed, 22 Apr 2009 10:28:42 -0700 (PDT) To: " Date: Wed, 22 Apr 2009 10:28:42 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Wed Apr 22 10:42:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8D13A6B76; Wed, 22 Apr 2009 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.031 X-Spam-Level: X-Spam-Status: No, score=-105.031 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 n2L4O4d-hWr9; Wed, 22 Apr 2009 10:42:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 568093A6820; Wed, 22 Apr 2009 10:42:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwgNx-0002Ol-KJ for namedroppers-data0@psg.com; Wed, 22 Apr 2009 17:37:25 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwgNj-0002Mr-ST for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 17:37:19 +0000 Received: from relay10.apple.com (relay10.apple.com [17.128.113.47]) by mail-out4.apple.com (Postfix) with ESMTP id 4F04260F0E1A; Wed, 22 Apr 2009 10:37:11 -0700 (PDT) Received: from relay10.apple.com (unknown [127.0.0.1]) by relay10.apple.com (Symantec Brightmail Gateway) with ESMTP id 3462728053; Wed, 22 Apr 2009 10:37:11 -0700 (PDT) X-AuditID: 1180712f-a996cbb0000012d3-ec-49ef55c754b2 Received: from [17.206.42.11] (chesh1.apple.com [17.206.42.11]) by relay10.apple.com (Apple SCV relay) with ESMTP id 1A3EF28050; Wed, 22 Apr 2009 10:37:11 -0700 (PDT) In-Reply-To: References: <4DB6B5E1-B18C-4812-8D4F-220120BFB96C@apple.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: IETF DNSEXT WG Content-Transfer-Encoding: 7bit From: Stuart Cheshire Subject: Re: [dnsext] NSEC for preemptive assertion of nonexistence Date: Wed, 22 Apr 2009 10:36:49 -0700 To: John Dickinson X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 22 Apr, 2009, at 01:47, John Dickinson wrote: > Could another option be to use the successor part of RFC4471? > > John Yes, I did think of that, but: (a) Implementation: It seems like a lot of work just to compute a value we intend to be ignored anyway. (b) Semantics: Computing ".name.example." as the successor to "name.example." to put in the NSEC record seems to be asserting that the name .name.example." does exist, when in fact it (probably) does not. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.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 Apr 22 11:12:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5C428C602; Wed, 22 Apr 2009 11:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.300, 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 5pUvKPBROi+C; Wed, 22 Apr 2009 11:12:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C961A3A7158; Wed, 22 Apr 2009 11:12:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwgtK-0005T8-1Z for namedroppers-data0@psg.com; Wed, 22 Apr 2009 18:09:50 +0000 Received: from [74.125.78.27] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwgt3-0005Ro-LT for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 18:09:43 +0000 Received: by ey-out-2122.google.com with SMTP id d26so32826eyd.65 for ; Wed, 22 Apr 2009 11:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=3J4nv5xlwsmO5L6LExPJTYzsWyCxAU/TNgaPiitPwgw=; b=KdWSoDcRVz4p9Y7mAICiuAmKOj1xkuqyzhsqVto+Jb80kJQdcarNsgLKNv+j4OzWWL 3KmYIqiACRfofNNui5LBPU10nnoU/5Z9iylgvxCeFyI/TyOq6ky5BXevhFF/uSeZ+s+n OtgdbGeA6Gy8gjTk6YBKkstH5jbgajmpjBI5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=JvlYkG+UvXp4Z/mt6OpIax5cIXlSsWTr4ygy3nW3Pqva7rLdHkxewcacP0WWh7ONXb +qtOcFivdNNzYdzIFTmA3j0Aq7eM2T29c+j5QfCBz2VBkBmvEnVDP/CvqQ6FN5UTkxNm M8IPYbtXCHGykJSTVzCtkfS1uu3OFiPdsMbg0= Received: by 10.210.126.18 with SMTP id y18mr6606482ebc.40.1240423771974; Wed, 22 Apr 2009 11:09:31 -0700 (PDT) Received: from ?192.168.1.204? ([193.82.161.205]) by mx.google.com with ESMTPS id 7sm8642912ewy.58.2009.04.22.11.09.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 11:09:31 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: From: John Dickinson To: Stuart Cheshire In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] NSEC for preemptive assertion of nonexistence Date: Wed, 22 Apr 2009 19:09:30 +0100 References: <4DB6B5E1-B18C-4812-8D4F-220120BFB96C@apple.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 22 Apr 2009, at 18:36, Stuart Cheshire wrote: > On 22 Apr, 2009, at 01:47, John Dickinson wrote: > >> Could another option be to use the successor part of RFC4471? >> >> John > > > Yes, I did think of that, but: > > (a) Implementation: It seems like a lot of work just to compute a > value we intend to be ignored anyway. Yes, I agree that may well be true and a very good reason not to do this. However, I don't think that in your case you would need to calculate the successor on the fly in response to every query would you? > > (b) Semantics: Computing ".name.example." as the successor to > "name.example." to put in the NSEC record seems to be asserting that > the name .name.example." does exist, when in fact it (probably) > does not. I don't agree, NSEC (especially as modified in 4470 and 4471) tells us that the space between two names is empty, it doesn't say anything about the existence of those two names. After all, isn't that the whole point of 4470 and 4471 - to prevent zone enumeration. John --- John Dickinson http://www.jadickinson.co.uk I am riding from Lands end to John O'Groats to raise money for Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009 -- to unsubscribe send a message to namedroppers-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 Apr 22 11:13:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD633A70D8; Wed, 22 Apr 2009 11:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=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 RyBSTVVPn1IV; Wed, 22 Apr 2009 11:13:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71A0F3A6CB3; Wed, 22 Apr 2009 11:13:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwgsl-0005Px-0f for namedroppers-data0@psg.com; Wed, 22 Apr 2009 18:09:15 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwgsM-0005O0-I9 for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 18:08:59 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3MI8kHk049859; Wed, 22 Apr 2009 14:08:46 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904221808.n3MI8kHk049859@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Apr 2009 14:08:38 -0400 To: Stuart Cheshire , IETF DNSEXT WG From: Olafur Gudmundsson Subject: Re: [dnsext] NSEC for preemptive assertion of nonexistence In-Reply-To: <4DB6B5E1-B18C-4812-8D4F-220120BFB96C@apple.com> References: <4DB6B5E1-B18C-4812-8D4F-220120BFB96C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 18:44 21/04/2009, Stuart Cheshire wrote: >2. Use own rrname, e.g. "stuartsprinter.local. 120 IN NSEC >stuartsprinter.local. A NSEC" > >- Less compact (unless name compression is used, which would violate >RFC 3845) >+ Seems semantically cleaner (but maybe not) > >This would seem semantically cleaner, except it may still not be >quite right. In a signed zone that contains nothing but a single name >at its apex, you'd have a self-referential NSEC record, something >like this: "minimal-zone.example. 2D IN NSEC minimal-zone.example. A >NS SOA NSEC". This is asserting that there are no (delegated or non- >delegated) subdomains of "minimal-zone.example." In our mDNS case, >this is more than we want to assert, since claiming ownership of >"foo.local." does not necessarily assert ownership of >"bar.foo.local." or any other names falling under "foo.local." > >However, I may not be understanding this quite right. In the parent >zone ("example.") there will also be an NSEC record, potentially >something like this: "minimal-zone.example. 2D IN NSEC next- >name.example. NS NSEC". That NSEC record is *not* asserting that the >name a.minimal-zone.example. does not exist, just that it does not >exist in the "example." zone. There are violations and there are Violations. In your case "stuartsprinter.local." is authorative for it self, but it is not advertising NS set nor a SOA ==> violation of contents of a DNS delegation. But in your system there are no delegations, there are only claims to names, thus your can strictly say NS and SOA are not need ==> you can draw any conclusions from: bar.local. NSEC bar.local. AAAA if foo.bar.local. exists or not. My recommendation is to use the same target name as the owner name. 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 Wed Apr 22 11:22:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCAE28C5EA; Wed, 22 Apr 2009 11:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_LOW=-1, 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 EWqBpVWrgvs2; Wed, 22 Apr 2009 11:22:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5BFB28C4AE; Wed, 22 Apr 2009 11:22:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwh3D-0006FZ-Mu for namedroppers-data0@psg.com; Wed, 22 Apr 2009 18:20:03 +0000 Received: from [88.198.34.164] (helo=mail.bofh.priv.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwh31-0006Eg-B6 for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 18:19:57 +0000 Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 1498B4C696 for ; Wed, 22 Apr 2009 20:19:49 +0200 (CEST) Message-ID: <49EF5FC2.3070007@nic.at> Date: Wed, 22 Apr 2009 20:19:46 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> In-Reply-To: <200904221507.n3MF7G6J047453@stora.ogud.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Some comments from my side: Ólafur Guðmundsson /DNSEXT chair wrote: > > Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ? > While this answers not the question directly, I think we should consider where the "expensiveness" happens: The cost varies between the authoritative server and the resolver. IMHO (and this is without having looked at the code), the server-side is rather trivial. No state. Just echo that record back. The resolver has the more difficult task: it has to keep state about the EDNS0 support level, worry about down-grade attacks and potentially resend the query without the EDNS0 ping. Who benefits from EDNS0? IMHO the resolver as he gets potentially better assurance that the answer is not faked. This is good: the party that reaps the benefit also has the most work to do. (e.g. ENUM is the other way round which killed its uptake) > Q1.5: Is the cost of Ping caused by it being the first/second option to be > standardized or will we have to suffer the same cost when options are > added in the future ? Updating the server side implementations to a better understanding on how to react on unknown EDNS0 options will also help with future EDNS0 options. (I haven't followed what happened to draft-ietf-dnsext-ends-unknown-00, but when reading up on EDNS0 I found no clear rules on treating unknown EDNS0 codes.) > Q2: Does ENDS0 Ping offer additional protection to > "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSEC" ? Both, as in the second case it can be used between the stub resolver and the validating recursor. > Q3: Are the benefits of ENDS0 Ping realized incrementally with > deployment or > only when the majority of code bases are deployed? Incrementally. > Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or the > producer? As mentioned above: the cost and the main benefits are on the client side. > Q6: Do you support that the WG adopt the document ? Yes. Reason: This is no panacea, but one way a simple code upgrade can significantly increase the security. Certainly not up to the level that DNSSEC could provide, but you just can't roll out DNSSEC with an automatic software upgrade. EDNS0 ping could be. And that's really important. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // -- to unsubscribe send a message to namedroppers-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 Apr 22 11:31:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9C73A69B3; Wed, 22 Apr 2009 11:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=-0.579, 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 qMgnjK3z1AHg; Wed, 22 Apr 2009 11:31:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB00928C0D8; Wed, 22 Apr 2009 11:30:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwhBP-0007EJ-A5 for namedroppers-data0@psg.com; Wed, 22 Apr 2009 18:28:31 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwhBD-0007Ce-21 for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 18:28:24 +0000 Received: by ewy2 with SMTP id 2so128951ewy.41 for ; Wed, 22 Apr 2009 11:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xdBtnOXj44QHlmi8mcevXM814eOiapyRsshPWwx2bmg=; b=IAs/cWzo8mBCw16gmsY0Z0ZKa1lrcdKg6t2fuTfa+k1FNNJXYakOhZAvHVJlYhlOTI zephq4V2wpLGwg/ZJTyzRh3jhNkEn6oLPYS8G/NsB7eyA+3k8PVMwZ8q3mOp2fzyzMMJ V6YDWFJ0ZaYh4Etqhkl8yemGmbubQNB6//13E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=pDU8+ycqalbEv8xSR0wAFFDzC63IBNfwvbV1lHNECRhmLN8ajD1Jrr/LGO4IqexcXN uv0F/3dKRiT1r2fVcbF4EBb4O4ivbrQe0618NkPaGUlbdtnKaB1IZ2Wr2jIFVuckadYI zJ1eTYrEOoVWxt2GpoKHqrZqGNajhrfkom9qA= MIME-Version: 1.0 Received: by 10.210.71.12 with SMTP id t12mr5717129eba.42.1240424897099; Wed, 22 Apr 2009 11:28:17 -0700 (PDT) In-Reply-To: References: <200904221507.n3MF7G6J047453@stora.ogud.com> From: bert hubert Date: Wed, 22 Apr 2009 20:28:02 +0200 Message-ID: <3efd34cc0904221128r4b339830ra905e003265ac0cc@mail.gmail.com> Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? To: Nicholas Weaver Cc: =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson_=2FDNSEXT_chair?= , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: 2009/4/22 Nicholas Weaver : > for DNSSEC, EDNS0 ping adds no confidence: =A0it is targeted against > out-of-path adversaries, while DNSSEC is targeted against both in-path an= d > out-of-path adversaries. It does add some robustness. Our goal should not purely be authenticity but also availability. >> Q6: Do you support that the WG adopt the document ? >> If your answer is NO is there any other mechanism you want considered ? >> Yes assumes you are willing to review future versions of the document. > > Yes. Thanks! > I believe there is some supporting survey data that should be conducted (= I > have already corresponded with Bob Herbert on some suggestions), and I > believe that fallback mechanisms should actually be discussed in the draf= t > (not currently present). Bob Herbert reporting :-) While I agree we should discuss strategies, or perhaps even better, add wise words on potential fallback mechanisms, I'm not convinced we can 'legislate' this in MUST or even SHOULD language. Olafur yesterday shared a great new idea with me on how to securely probe for EDNS0 support in a non-downgradeable way. I'm sure even better ideas will come along. I'd hate to require certain strategies when what we should be enabling is the invention of even better strategies. Bert -- to unsubscribe send a message to namedroppers-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 Apr 22 11:59:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227E828C612; Wed, 22 Apr 2009 11:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.941 X-Spam-Level: X-Spam-Status: No, score=-104.941 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 OYZRxCs90GgN; Wed, 22 Apr 2009 11:59:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAAFD28C628; Wed, 22 Apr 2009 11:59:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwhcN-0009of-0E for namedroppers-data0@psg.com; Wed, 22 Apr 2009 18:56:23 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwhc4-0009lo-V7 for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 18:56:16 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 582865E1844D for ; Wed, 22 Apr 2009 11:56:04 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 3B72128088 for ; Wed, 22 Apr 2009 11:56:04 -0700 (PDT) X-AuditID: 1180711d-abefbbb000000259-6f-49ef6844b26e Received: from [17.206.42.11] (chesh1.apple.com [17.206.42.11]) by relay13.apple.com (Apple SCV relay) with ESMTP id 2097828086 for ; Wed, 22 Apr 2009 11:56:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: <2EF3EE9C-31EF-4964-AD21-AF06D19DD450@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF DNSEXT WG From: Stuart Cheshire Subject: [dnsext] "Network bit order" in RFC 3845 Date: Wed, 22 Apr 2009 11:55:42 -0700 X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: AAAAAA== Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: RFC 3845 says: Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. What the hell does that mean? Of course the "first" bit is bit 0. Everyone agrees on that. The problem is that people don't agree which bit is "first", hence the need to specify an order. A Google search for "network bit order" finds... drum roll... RFC 3845. Not very helpful. Is bit 'x' the bit with value 2^x, or the bit with value 2^(n-1-x) (where 'n' is 8 in this case, because we're dealing with 8-bit bytes)? From the example later in the RFC, I'm guessing the latter. So this means that we're assuming big-endian bit order within the byte (i.e. the "first" bit is the most significant one). However, also from the example, it appears that the order of the bytes in the 256-bit bitmap is little-endian (i.e. the least significant bits, 0-7, go in the first byte, the next most significant bits, 8-15, go in the second byte, and so on). So in summary: The order of the bytes in the block is little-endian (first byte is least significant eight bits of the 256-bit bitmap) The order of the bits in each byte is big-endian (the first bit of each group of eight goes in the most significant bit of the byte) i.e. the expression to see if bit 'x' is set is not: if (byte[x/8] & (1 << (x%8))) // then bit x is set but in fact: if (byte[x/8] & (1 << (7 - (x%8)))) // then bit x is set As x increases, we move forward through the bytes in the block, but backwards through the bits of each byte. Do I have that correct? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.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 Apr 22 12:21:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D4628C4B8; Wed, 22 Apr 2009 12:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.44 X-Spam-Level: X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[AWL=-0.392, 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 a8HUwkTdDZXw; Wed, 22 Apr 2009 12:21:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D4ED3A6C36; Wed, 22 Apr 2009 12:21:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwhx6-000BU4-Oi for namedroppers-data0@psg.com; Wed, 22 Apr 2009 19:17:48 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwhwn-000BSc-Mh for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 19:17:41 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3MJHKuB021108; Wed, 22 Apr 2009 12:17:20 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> From: Nicholas Weaver To: Otmar Lendl In-Reply-To: <49EF5FC2.3070007@nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Wed, 22 Apr 2009 12:17:19 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 22, 2009, at 11:19 AM, Otmar Lendl wrote: > > Some comments from my side: > > =D3lafur Gu=F0mundsson /DNSEXT chair wrote: >> >> Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ? > > The resolver has the more difficult task: it has to keep state about =20= > the > EDNS0 support level, worry about down-grade attacks and potentially =20= > resend > the query without the EDNS0 ping. There is no real such thing as a downgrade attack on EDNS0 ping: To do a downgrade, an attacker would need to be in-path. And in-path =20= attacker are not affected by EDNS0 ping. Rather, what needs to be considered is "what if there is no support =20 for EDNS ping" and IMO, I believe that should be in the draft.. >> Q2: Does ENDS0 Ping offer additional protection to >> "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSEC" ? > > Both, as in the second case it can be used between the stub resolver =20= > and > the validating recursor. If you want the benefits of DNSSEC, the stub, not the recursor, MUST =20 be the validator. Since the recursor is an untrustworthy part in =20 DNSSEC. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 22 13:53:53 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3152428C66C; Wed, 22 Apr 2009 13:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 MzdVVcDxOAAO; Wed, 22 Apr 2009 13:53:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5152328C634; Wed, 22 Apr 2009 13:53:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwjNV-000IbY-2C for namedroppers-data0@psg.com; Wed, 22 Apr 2009 20:49:09 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwjNI-000Iaa-Mh for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 20:49:02 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DE4142FE9583 for ; Wed, 22 Apr 2009 20:48:54 +0000 (UTC) Date: Wed, 22 Apr 2009 16:48:52 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090422204852.GA67667@shinkuro.com> References: <200904221507.n3MF7G6J047453@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Apr 22, 2009 at 09:08:34AM -0700, Nicholas Weaver wrote: >> Q2: Does ENDS0 Ping offer additional protection to >> "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSSEC" ? > > "Non-DNSSEC DNS": > > for DNSSEC, EDNS0 ping adds no confidence: it is targeted against out- > of-path adversaries, while DNSSEC is targeted against both in-path and > out-of-path adversaries. This is a question, and only a question (i.e. not a comment pretending to be a question). I'm asking this as co-chair, as part of an effort to understand why you think the adoption is worth it. I think you're saying that (1) we need to upgrade resolvers to do EDNS0 Ping and (2) it does not really offer any benefit not already offered by DNSSEC. Is that right? If so, then why do EDNS0 Ping at all? If not, what did I misunderstand in what you said? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 22 14:22:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0391428C2A4; Wed, 22 Apr 2009 14:22:02 -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=[BAYES_00=-2.599, HELO_LH_HOME=3.714] 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 QQ5mo7mb0Hxa; Wed, 22 Apr 2009 14:21:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F6593A6F79; Wed, 22 Apr 2009 14:21:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwjpm-000Kg5-2f for namedroppers-data0@psg.com; Wed, 22 Apr 2009 21:18:22 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe52:9971] (helo=mail2.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwjpZ-000KfD-An for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 21:18:15 +0000 Received: from firewall.antoniuk.lan (mail.antoniuk.md [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 385D039905; Wed, 22 Apr 2009 21:18:08 +0000 (UTC) (envelope-from mayer@gis.net) Received: from [208.71.36.125] (helo=[131.106.57.238]) by firewall.antoniuk.lan with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1LwjpO-0003Zf-6K; Wed, 22 Apr 2009 17:17:58 -0400 Message-ID: <49EF897E.6090000@gis.net> Date: Wed, 22 Apr 2009 17:17:50 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Vixie Cc: Michael Graff , "Jeffrey A. Williams" , =?ISO-8859-1?Q?Ond=3Fej_Sur=FD?= , Dan Simon , "namedroppers@ops.ietf.org" , doc/ntia DNSSEC , USTR General contact Subject: DNSSEC-aware applications (was [dnsext] Re: Request for adoption) References: <49DB20B8.7020505@cryptocom.ru> <20090413200602.GC24286@shinkuro.com> <49E70058.75AA073B@ix.netcom.com> <49E70766.3030602@isc.org> <65829.1239890085@nsa.vix.com> In-Reply-To: <65829.1239890085@nsa.vix.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-kostecke.net-MailScanner: Found to be clean X-kostecke.net-MailScanner-From: mayer@gis.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > i've been flogging dnssec all these years not because of problems that a > larger TID or universal deployment of BCP38 would have solved, but because > i want to enable to creation of new dnssec-aware applications which behave > differently in the presence of signed data. there is no way to justify > dnssec's costs (to date or as projected) on the basis of kaminsky alone. > > --paul Talking of DNSSEC-aware applications, how is this going to happen? Currently all there is for an application is to use getaddrinfo() which returns a result. The application cannot tell getaddrinfo() that it only wants secure answers, getaddrinfo() cannot tell you whether the answer was secure, how long it is valid (TTL) or any other information that would allow to make a determination on the validity or value of the data returned. Usually you get the list of DNS servers to use to do lookups from DHCP and you have no way of telling DHCP that you want only DNSSEC-aware servers. You cannot even tell whether or not those DNS servers are DNSSEC-aware without some sample queries (assuming it doesn't lie to you). This gets really bad when you travel or just go to your nearest coffee shop with a wireless access point. Let's say you want to check your bank balance at the Gigantic Bank of Money using a browser like firefox or ie. You want a secure connection so you want to use https and you want to make sure that the IP addresses returned by DNS actually is the Bank's web site. So you want to require DNSSEC to be used for the lookup but when you go off to request that web page but you also want to ensure that any additional data included in that page references DNSSEC-secured addresses required to load those pages. Then of course you want to tell your browser which domains *require* DNSSEC-secured address and there's no way to tell it that either. We want DNSSEC-aware applications but we also need additional infrastructure in place to do it. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- to unsubscribe send a message to namedroppers-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 Apr 22 14:37:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDBEC28C25C; Wed, 22 Apr 2009 14:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 uVSS6pXIgc5o; Wed, 22 Apr 2009 14:37:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1464B3A6F8E; Wed, 22 Apr 2009 14:37:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwk59-000M04-Sa for namedroppers-data0@psg.com; Wed, 22 Apr 2009 21:34:15 +0000 Received: from [209.85.200.173] (helo=wf-out-1314.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwk4w-000LyV-Gp for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 21:34:09 +0000 Received: by wf-out-1314.google.com with SMTP id 29so159668wff.32 for ; Wed, 22 Apr 2009 14:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.144.9 with SMTP id r9mr78430wfd.91.1240436040403; Wed, 22 Apr 2009 14:34:00 -0700 (PDT) In-Reply-To: <20090422204852.GA67667@shinkuro.com> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <20090422204852.GA67667@shinkuro.com> Date: Wed, 22 Apr 2009 14:34:00 -0700 Message-ID: Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? From: Matthew Dempsky To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Apr 22, 2009 at 1:48 PM, Andrew Sullivan wrote: > I think you're saying that (1) we need to upgrade resolvers to do > EDNS0 Ping and (2) it does not really offer any benefit not already > offered by DNSSEC. =A0Is that right? =A0If so, then why do EDNS0 Ping at > all? =A0If not, what did I misunderstand in what you said? Supporting EDNS Ping just requires upgrading resolvers and authoritative servers. It doesn't require any additional configuration work from the administrators. -- to unsubscribe send a message to namedroppers-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 Apr 22 14:56:40 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6CE3A6CC7; Wed, 22 Apr 2009 14:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 tagged_above=-999 required=5 tests=[AWL=-0.379, 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 v0phlt0d7XiO; Wed, 22 Apr 2009 14:56:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 977B93A6E37; Wed, 22 Apr 2009 14:55:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwkMy-000NYR-1T for namedroppers-data0@psg.com; Wed, 22 Apr 2009 21:52:40 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwkMg-000NWh-4D for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 21:52:29 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3MLqKam006234; Wed, 22 Apr 2009 14:52:20 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <994733BF-8E35-47F7-8967-19BB6381F229@icsi.berkeley.edu> From: Nicholas Weaver To: Andrew Sullivan In-Reply-To: <20090422204852.GA67667@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Wed, 22 Apr 2009 14:52:20 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <20090422204852.GA67667@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 22, 2009, at 1:48 PM, Andrew Sullivan wrote: > On Wed, Apr 22, 2009 at 09:08:34AM -0700, Nicholas Weaver wrote: > >>> Q2: Does ENDS0 Ping offer additional protection to >>> "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSSEC" ? >> >> "Non-DNSSEC DNS": >> >> for DNSSEC, EDNS0 ping adds no confidence: it is targeted against >> out- >> of-path adversaries, while DNSSEC is targeted against both in-path >> and >> out-of-path adversaries. > > This is a question, and only a question (i.e. not a comment pretending > to be a question). I'm asking this as co-chair, as part of an effort > to understand why you think the adoption is worth it. > > I think you're saying that (1) we need to upgrade resolvers to do > EDNS0 Ping and (2) it does not really offer any benefit not already > offered by DNSSEC. Is that right? If so, then why do EDNS0 Ping at > all? If not, what did I misunderstand in what you said? IF we could, by magic, get DNSSEC adopted, my view is EDNS ping does nothing. However, getting DNSSEC adopted is, I believe, a MUCH harder hurdle than EDNS0 Ping. EDNS0 ping is a trivially small patch on the authority code side, and a very small patch on the resolver code side, and really requires no intervention from operators beyond installing the patch. Since you need fallback/treatment on the resolver side when the authority doesnt' support it anyway, you don't even have to worry about the stupid firewalls (you'll just be in always-fallback in that case). DNSSEC, on the other hand, has some severe problems, including turning many misconfigurations (eg, stale keys, etc) into full denial of service conditions. There's no established roots of trust to actually trust, deployment on the authority side requires MANY headaches, and there doesn't even exist a proper API for applications to really use DNSSEC as gethostbyname() is obviously not the correct answer for DNSSEC, etc... Thus although 1 and 2 are correct, it forgets 3: EDNS0 ping is orders of magnitude simpler, and thus can put the final nail in the coffin on out-of-path attackers in a practical, deployable manner today. -- to unsubscribe send a message to namedroppers-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 Apr 22 16:48:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7703A6FA3; Wed, 22 Apr 2009 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.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 puF74jwQITuv; Wed, 22 Apr 2009 16:48:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6481A3A719F; Wed, 22 Apr 2009 16:48:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwm6A-0005Ny-Dl for namedroppers-data0@psg.com; Wed, 22 Apr 2009 23:43:26 +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 1Lwm5x-0005Mo-Ui for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 23:43:19 +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 n3MNYcw4026046; Wed, 22 Apr 2009 19:34:38 -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); Wed, 22 Apr 2009 19:43:09 -0400 Received: from dul1mcdblacka-l2.vcorp.ad.vrsn.com ([10.131.29.149]) by dul1wnexmb02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 19:43:08 -0400 Cc: Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <45F7A5A8-DDB3-4305-9CA9-260AA0C72E32@verisign.com> From: David Blacka To: Nicholas Weaver In-Reply-To: <994733BF-8E35-47F7-8967-19BB6381F229@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Wed, 22 Apr 2009 19:42:40 -0400 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <20090422204852.GA67667@shinkuro.com> <994733BF-8E35-47F7-8967-19BB6381F229@icsi.berkeley.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Apr 2009 23:43:08.0480 (UTC) FILETIME=[17018C00:01C9C3A4] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 22, 2009, at 5:52 PM, Nicholas Weaver wrote: > > On Apr 22, 2009, at 1:48 PM, Andrew Sullivan wrote: > >> On Wed, Apr 22, 2009 at 09:08:34AM -0700, Nicholas Weaver wrote: >> >>>> Q2: Does ENDS0 Ping offer additional protection to >>>> "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSSEC" ? >>> >>> "Non-DNSSEC DNS": >>> >>> for DNSSEC, EDNS0 ping adds no confidence: it is targeted against >>> out- >>> of-path adversaries, while DNSSEC is targeted against both in-path >>> and >>> out-of-path adversaries. >> >> This is a question, and only a question (i.e. not a comment >> pretending >> to be a question). I'm asking this as co-chair, as part of an effort >> to understand why you think the adoption is worth it. >> >> I think you're saying that (1) we need to upgrade resolvers to do >> EDNS0 Ping and (2) it does not really offer any benefit not already >> offered by DNSSEC. Is that right? If so, then why do EDNS0 Ping at >> all? If not, what did I misunderstand in what you said? > > IF we could, by magic, get DNSSEC adopted, my view is EDNS ping does > nothing. Doesn't it make it harder for an off-path attacker to DoS you? Or is that problem already considered solved? -- David Blacka Sr. Engineer VeriSign 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 Wed Apr 22 16:59:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211EA3A6F79; Wed, 22 Apr 2009 16:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.416 X-Spam-Level: X-Spam-Status: No, score=-5.416 tagged_above=-999 required=5 tests=[AWL=-0.368, 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 tVuyDoRWwVeP; Wed, 22 Apr 2009 16:59:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D21833A6934; Wed, 22 Apr 2009 16:56:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwmGG-00063l-5o for namedroppers-data0@psg.com; Wed, 22 Apr 2009 23:53:52 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwmG4-00062n-8v for namedroppers@ops.ietf.org; Wed, 22 Apr 2009 23:53:45 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3MNrcA3015850; Wed, 22 Apr 2009 16:53:39 -0700 (PDT) Cc: Nicholas Weaver , Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <03235E14-D00C-458A-82B8-271190E43B9F@ICSI.Berkeley.EDU> From: Nicholas Weaver To: David Blacka In-Reply-To: <45F7A5A8-DDB3-4305-9CA9-260AA0C72E32@verisign.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Wed, 22 Apr 2009 16:53:38 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <20090422204852.GA67667@shinkuro.com> <994733BF-8E35-47F7-8967-19BB6381F229@icsi.berkeley.edu> <45F7A5A8-DDB3-4305-9CA9-260AA0C72E32@verisign.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 22, 2009, at 4:42 PM, David Blacka wrote: >> >> IF we could, by magic, get DNSSEC adopted, my view is EDNS ping >> does nothing. > > Doesn't it make it harder for an off-path attacker to DoS you? Or > is that problem already considered solved? An off-path attacker, even without port randomization, requires a huge amount of traffic to DOS, especially if on first-DNSSEC failure you do a retry, that an off-path attacker might as well just do a traffic DOS instead. -- to unsubscribe send a message to namedroppers-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 Apr 22 17:30:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2AA3A6C76; Wed, 22 Apr 2009 17:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 x2ZxDTa-2l55; Wed, 22 Apr 2009 17:30:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2E3E3A6B55; Wed, 22 Apr 2009 17:30:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwmlr-0008WE-Mc for namedroppers-data0@psg.com; Thu, 23 Apr 2009 00:26:31 +0000 Received: from [74.125.46.31] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwmlY-0008Uw-TC for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 00:26:20 +0000 Received: by yw-out-2324.google.com with SMTP id 3so196570ywj.71 for ; Wed, 22 Apr 2009 17:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2d/z6qNeLzvHCsT8Ya/BiUMmy+9QGDjFU+XdPGi/Fgo=; b=PxiK4cTttpTfN5OMKfMhtzIyn/42UxOjGE+/EU+BMdgGpo1ZyzmGD9Bpw28tFnbivu wDiYT0q8pCqwsz/FZ7M/XKQjAcsfYP14AUyHa7z/v6fb/THXB/+yvZkYQ3GAisTcNoO5 fVBVmErxV8UQS30KkHsc2u/G3XyUylbZK6D7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I1z4u+UUiuZnuCd+7MrflRxDoAgun0KsOdcrWAQDn9EZTxg87zAgVPGuZ8GTeA5oG4 EG6WxbzSMg13RdcyUH5i4mCxDmHO+/Zx5LFHC9RqrOIwVeQXiL5+gkw3nuz3xftE8z3V uLGqs9h5BxQW488e1Lrvy7IRX6YWxmLdrQpUg= MIME-Version: 1.0 Received: by 10.100.172.17 with SMTP id u17mr561581ane.30.1240446372215; Wed, 22 Apr 2009 17:26:12 -0700 (PDT) In-Reply-To: <2EF3EE9C-31EF-4964-AD21-AF06D19DD450@apple.com> References: <2EF3EE9C-31EF-4964-AD21-AF06D19DD450@apple.com> Date: Wed, 22 Apr 2009 20:26:12 -0400 Message-ID: <1028365c0904221726i7b045d89k840fc15273cb52ac@mail.gmail.com> Subject: Re: [dnsext] "Network bit order" in RFC 3845 From: Donald Eastlake To: Stuart Cheshire Cc: IETF DNSEXT WG Content-Type: multipart/alternative; boundary=0016368e1c0d60fcde04682dedf3 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --0016368e1c0d60fcde04682dedf3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You wanted to look up "network order" which is mentioned in many RFCs starting at least as early as RFC 1235. Donald On Wed, Apr 22, 2009 at 2:55 PM, Stuart Cheshire wrote: > RFC 3845 says: > > Each bitmap encodes the low-order 8 bits of RR types within the > window block, in network bit order. The first bit is bit 0. > > What the hell does that mean? > > Of course the "first" bit is bit 0. Everyone agrees on that. The problem is > that people don't agree which bit is "first", hence the need to specify an > order. > > A Google search for "network bit order" finds... drum roll... RFC 3845. Not > very helpful. > > Is bit 'x' the bit with value 2^x, or the bit with value 2^(n-1-x) (where > 'n' is 8 in this case, because we're dealing with 8-bit bytes)? > > From the example later in the RFC, I'm guessing the latter. > > So this means that we're assuming big-endian bit order within the byte > (i.e. the "first" bit is the most significant one). > > However, also from the example, it appears that the order of the bytes in > the 256-bit bitmap is little-endian (i.e. the least significant bits, 0-7, > go in the first byte, the next most significant bits, 8-15, go in the second > byte, and so on). > > So in summary: > > The order of the bytes in the block is little-endian (first byte is least > significant eight bits of the 256-bit bitmap) > The order of the bits in each byte is big-endian (the first bit of each > group of eight goes in the most significant bit of the byte) > > i.e. the expression to see if bit 'x' is set is not: > > if (byte[x/8] & (1 << (x%8))) // then bit x is set > > but in fact: > > if (byte[x/8] & (1 << (7 - (x%8)))) // then bit x is set > > As x increases, we move forward through the bytes in the block, but > backwards through the bits of each byte. > > Do I have that correct? > > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * Internet Architecture Board > * www.stuartcheshire.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: > -- ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com --0016368e1c0d60fcde04682dedf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You wanted to look up "network order" which is mentioned in many = RFCs starting at least as early as RFC 1235.

Donald
<= br>
On Wed, Apr 22, 2009 at 2:55 PM, Stuart Chesh= ire <cheshire@ap= ple.com> wrote:
RFC 3845 says:

=A0 Each bitmap encodes the low-order 8 bits of RR types within the
=A0 window block, in network bit order. =A0The first bit is bit 0.

What the hell does that mean?

Of course the "first" bit is bit 0. Everyone agrees on that. The = problem is that people don't agree which bit is "first", henc= e the need to specify an order.

A Google search for "network bit order" finds... drum roll... RFC= 3845. Not very helpful.

Is bit 'x' the bit with value 2^x, or the bit with value 2^(n-1-x) = (where 'n' is 8 in this case, because we're dealing with 8-bit = bytes)?

>From the example later in the RFC, I'm guessing the latter.

So this means that we're assuming big-endian bit order within the byte = (i.e. the "first" bit is the most significant one).

However, also from the example, it appears that the order of the bytes in t= he 256-bit bitmap is little-endian (i.e. the least significant bits, 0-7, g= o in the first byte, the next most significant bits, 8-15, go in the second= byte, and so on).

So in summary:

The order of the bytes in the block is little-endian (first byte is least s= ignificant eight bits of the 256-bit bitmap)
The order of the bits in each byte is big-endian (the first bit of each gro= up of eight goes in the most significant bit of the byte)

i.e. the expression to see if bit 'x' is set is not:

if (byte[x/8] & (1 << (x%8))) // then bit x is set

but in fact:

if (byte[x/8] & (1 << (7 - (x%8)))) // then bit x is set

As x increases, we move forward through the bytes in the block, but backwar= ds through the bits of each byte.

Do I have that correct?

Stuart Cheshire <cheshire@apple.com>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartche= shire.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: <http://ops.ietf.org/lists/namedroppers/>



--
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd =A0 +1-508-634-2066 (home)
155 Beaver Street Milford, MA 01757 USA
d3e3e3@gma= il.com
--0016368e1c0d60fcde04682dedf3-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From arlosblanco@playstation.sony.com Wed Apr 22 23:31:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89B13A6997; Wed, 22 Apr 2009 23:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.1 X-Spam-Level: X-Spam-Status: No, score=-24.1 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DYNAMIC=1.144, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN0b=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 eXBxz8FYqj5r; Wed, 22 Apr 2009 23:31:47 -0700 (PDT) Received: from 59-112-225-60.dynamic.hinet.net (59-112-225-60.dynamic.hinet.net [59.112.225.60]) by core3.amsl.com (Postfix) with SMTP id 83CAF28C680; Wed, 22 Apr 2009 23:31:36 -0700 (PDT) From: "Herminia Langston" To: <"dix-request@ietf.org, dnsext-archive@ietf.org, dnsind-archive@ietf.org, dnsop@ietf.org, drums-archive@ietf.org, eap-archive@ietf.org, ecrit@ietf.org, ecrit-bounces@ietf.org, ecrit-owner"@ietf.org> Subject: Affordable rep watches Date: Thu, 23 Apr 2009 02:32:56 -0500 Message-ID: <2393glz526034HCNAdix-request@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 090119-0, 2009/01/19), Outbound message X-Antivirus-Status: Clean Loving yourself is the first step in loving life. And what better way to do it, than by getting yourself a fine designer watch? http://www.bujawaqag.cn The watch of your dreams doesn't have to be an overpriced piece of machinery. Nowadays you can get the same functionality and distinctive looks from the next best thing. Visit Diam0nd Reps and choose from hundreds of gorgeous models at less than ten percent the price of an original. http://www.bujawaqag.cn Check out our extensive inventory and enjoy the fastest shipping available online! See you at Diam0nd Reps! From owner-namedroppers@ops.ietf.org Thu Apr 23 00:29:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584883A71CF; Thu, 23 Apr 2009 00:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 XWoWdo2LkSw1; Thu, 23 Apr 2009 00:29:23 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A03843A71C6; Thu, 23 Apr 2009 00:29:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwtJh-000BR9-Hz for namedroppers-data0@psg.com; Thu, 23 Apr 2009 07:25:53 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwtJU-000BQP-4u for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 07:25:46 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 767B51C00EE; Thu, 23 Apr 2009 09:25:39 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 725521C00E1; Thu, 23 Apr 2009 09:25:39 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 66FFBA1D9A3; Thu, 23 Apr 2009 09:25:39 +0200 (CEST) Date: Thu, 23 Apr 2009 09:25:39 +0200 From: Stephane Bortzmeyer To: Otmar Lendl Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090423072539.GC6975@nic.fr> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EF5FC2.3070007@nic.at> X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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 Wed, Apr 22, 2009 at 08:19:46PM +0200, Otmar Lendl wrote a message of 70 lines which said: > The cost varies between the authoritative server and the resolver. > > IMHO (and this is without having looked at the code), the server-side is > rather trivial. No state. Just echo that record back. There is another cost for the authoritative server which did not upgrade to edns-ping: an increase in the number of queries by edns-ping resolvers trying to find out if there was a downgrade attack or if the authoritative server really does not support edns-ping. Not a big problem, IMHO, but it should be mentioned for completeness. -- to unsubscribe send a message to namedroppers-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 Apr 23 00:29:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE173A71C6; Thu, 23 Apr 2009 00:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.833 X-Spam-Level: X-Spam-Status: No, score=-105.833 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 9BLNNLNBslwj; Thu, 23 Apr 2009 00:29:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B887A3A71D2; Thu, 23 Apr 2009 00:29:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwtHN-000BHr-M5 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 07:23:29 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwtH5-000BGA-Al for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 07:23:22 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id F172E1C00EE; Thu, 23 Apr 2009 09:23:09 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id EC6F41C00E1; Thu, 23 Apr 2009 09:23:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id EA248A1D9A3; Thu, 23 Apr 2009 09:23:09 +0200 (CEST) Date: Thu, 23 Apr 2009 09:23:09 +0200 From: Stephane Bortzmeyer To: bert hubert Cc: "namedroppers@ops.ietf.org" Subject: [dnsext] Re: Request for adoption of draft-hubert-ulevitch-edns-ping.txt as a working group document Message-ID: <20090423072309.GB6975@nic.fr> References: <3efd34cc0904201331s32f7882bv95119df436829a03@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <3efd34cc0904201331s32f7882bv95119df436829a03@mail.gmail.com> X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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: --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2009 at 10:31:30PM +0200, bert hubert wrote=20 a message of 26 lines which said: > would like to submit the EDNS-PING draft as a working group > document. I support the adoption (and I volunteer for the reviewing).=20 The way I see the DNS security issues, DNSSEC solves most of the problems (except hijacking on the registrar or registry side but it is off-topic for the DNS, see ). But DNSSEC is painful to deploy, not because of software but because of social infrastructure (see Matthew Dempsky's response to Andrew Sullivan). So, we *need* as much forgery resilience as possible, we need a RFC 5452++. I am aware that edns-ping protects only the channel, not the data, but it is "better than nothing" security. Several forgery resilience are on the table such as 0x20. To me, cookies and edns-ping are good ideas because, conceptually, they just increase the width of the Query ID, whose small size is at the root of many DNS weaknesses. My personal preference go to cookies. But I understand that there are non-technical issues which prevent its adoption. So, edns-ping is a reasonable substitute. --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJ8BddQTZHl5fW0kYRAq4QAJ91XyCP7HKkjIoGvwBSwX8FpIjrfQCgl+cl 3HfWIU1tEq2lLks87MGqYGE= =BoLg -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- -- to unsubscribe send a message to namedroppers-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 Apr 23 01:08:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2CC73A71DC; Thu, 23 Apr 2009 01:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_ASCII0=1.5, 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 2AnTJBPGJn4N; Thu, 23 Apr 2009 01:07:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 129A33A71DF; Thu, 23 Apr 2009 01:07:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwtuu-000FPL-2R for namedroppers-data0@psg.com; Thu, 23 Apr 2009 08:04:20 +0000 Received: from [194.100.2.122] (helo=smtp2.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwtuY-000FNS-QK for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 08:04:05 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp2.tdc.fi (Postfix) with ESMTP id 62D976B00FC for ; Thu, 23 Apr 2009 11:03:48 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 11:01:22 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Thread-Index: AcnD6Hw9mqJv4CFQSGmvbrlTGACAXAAARPXw References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1uYW1lZHJvcHBlcnNA b3BzLmlldGYub3JnIFttYWlsdG86b3duZXItDQo+IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBTdGVwaGFuZSBCb3J0em1leWVyDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJp bCAyMywgMjAwOSAxMDoyNiBBTQ0KPiBUbzogT3RtYXIgTGVuZGwNCj4gQ2M6IG5hbWVkcm9wcGVy c0BvcHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogW2Ruc2V4dF0gUmU6IEFkb3B0IEVETlMwIFBpbmcs IGJlbmVmaXRzIHZzIGRpc2FkdmFudGFnZXMgPw0KPiANCj4gT24gV2VkLCBBcHIgMjIsIDIwMDkg YXQgMDg6MTk6NDZQTSArMDIwMCwNCj4gIE90bWFyIExlbmRsIDxsZW5kbEBuaWMuYXQ+IHdyb3Rl DQo+ICBhIG1lc3NhZ2Ugb2YgNzAgbGluZXMgd2hpY2ggc2FpZDoNCj4gDQo+ID4gVGhlIGNvc3Qg dmFyaWVzIGJldHdlZW4gdGhlIGF1dGhvcml0YXRpdmUgc2VydmVyIGFuZCB0aGUgcmVzb2x2ZXIu DQo+ID4NCj4gPiBJTUhPIChhbmQgdGhpcyBpcyB3aXRob3V0IGhhdmluZyBsb29rZWQgYXQgdGhl IGNvZGUpLCB0aGUgc2VydmVyLXNpZGUNCj4gaXMNCj4gPiByYXRoZXIgdHJpdmlhbC4gTm8gc3Rh dGUuIEp1c3QgZWNobyB0aGF0IHJlY29yZCBiYWNrLg0KPiANCj4gVGhlcmUgaXMgYW5vdGhlciBj b3N0IGZvciB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgd2hpY2ggZGlkIG5vdA0KPiB1cGdyYWRl IHRvIGVkbnMtcGluZzogYW4gaW5jcmVhc2UgaW4gdGhlIG51bWJlciBvZiBxdWVyaWVzIGJ5DQo+ IGVkbnMtcGluZyByZXNvbHZlcnMgdHJ5aW5nIHRvIGZpbmQgb3V0IGlmIHRoZXJlIHdhcyBhIGRv d25ncmFkZSBhdHRhY2sNCj4gb3IgaWYgdGhlIGF1dGhvcml0YXRpdmUgc2VydmVyIHJlYWxseSBk b2VzIG5vdCBzdXBwb3J0IGVkbnMtcGluZy4gTm90DQo+IGEgYmlnIHByb2JsZW0sIElNSE8sIGJ1 dCBpdCBzaG91bGQgYmUgbWVudGlvbmVkIGZvciBjb21wbGV0ZW5lc3MuDQo+IA0KPiANCg0KSSB0 aGluayBhbnkgc29sdXRpb24gc3VmZmVycyBmcm9tIHRoaXMgZHJhd2JhY2ssIG5vdCBqdXN0IEVE TlMwIFBJTkcuIA0KDQo+IC0tDQo+IHRvIHVuc3Vic2NyaWJlIHNlbmQgYSBtZXNzYWdlIHRvIG5h bWVkcm9wcGVycy1yZXF1ZXN0QG9wcy5pZXRmLm9yZyB3aXRoDQo+IHRoZSB3b3JkICd1bnN1YnNj cmliZScgaW4gYSBzaW5nbGUgbGluZSBhcyB0aGUgbWVzc2FnZSB0ZXh0IGJvZHkuDQo+IGFyY2hp dmU6IDxodHRwOi8vb3BzLmlldGYub3JnL2xpc3RzL25hbWVkcm9wcGVycy8+DQo= -- to unsubscribe send a message to namedroppers-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 Apr 23 01:35:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D97B3A71DC; Thu, 23 Apr 2009 01:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.845 X-Spam-Level: X-Spam-Status: No, score=-105.845 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 As-JJlYkosRS; Thu, 23 Apr 2009 01:35:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 466193A6D63; Thu, 23 Apr 2009 01:35:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwuLj-000HgM-7M for namedroppers-data0@psg.com; Thu, 23 Apr 2009 08:32:03 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwuLW-000HfH-7R for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 08:31:56 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 40EA91C0104; Thu, 23 Apr 2009 10:31:49 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 3C3921C00EF; Thu, 23 Apr 2009 10:31:49 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 309BD7B0063; Thu, 23 Apr 2009 10:31:49 +0200 (CEST) Date: Thu, 23 Apr 2009 10:31:49 +0200 From: Stephane Bortzmeyer To: Aki Tuomi Cc: namedroppers@ops.ietf.org Subject: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090423083149.GA17599@nic.fr> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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 Thu, Apr 23, 2009 at 11:01:22AM +0300, Aki Tuomi wrote a message of 33 lines which said: > I think any solution suffers from this drawback, not just EDNS0 PING. Before Paul Vixie steps in, I can quote his reasoning: with 0x20, today, the majority of name servers is already compliant and will not suffer for the increase of queries. With cookies or edns-ping, today, the majority of name servers is not compliant. Not a big deal, IMHO, the increased channel security is worth it, but it is something to keep in mind. -- to unsubscribe send a message to namedroppers-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 Apr 23 02:36:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B363A71BD; Thu, 23 Apr 2009 02:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.146 X-Spam-Level: *** X-Spam-Status: No, score=3.146 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, 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 kAdqp1F5CEpx; Thu, 23 Apr 2009 02:36:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1606F28C69C; Thu, 23 Apr 2009 02:36:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwvIG-000MOS-7H for namedroppers-data0@psg.com; Thu, 23 Apr 2009 09:32:32 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwvI1-000MMZ-HY for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 09:32:25 +0000 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1LwvHz-00056x-Vk for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 10:32:16 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1LwvHu-0002a4-8k for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 10:32:10 +0100 Message-ID: <749B34748D4A47DBBE0053A5920CF736@localhost> From: "George Barwood" To: References: <200904221507.n3MF7G6J047453@stora.ogud.com> Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 10:32:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Ólafur Guðmundsson /DNSEXT chair" To: Sent: Wednesday, April 22, 2009 4:07 PM Subject: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? > The WG has received a request to adopt this as a work item. > See draft: > http://www.ietf.org/internet-drafts/draft-hubert-ulevitch-edns-ping-01.txt > > The current document falls under the "further Forgery Resilience" clause > in > our charter. > > If we are going to debate the merits of this proposal, the chairs think > it is going to beneficial to all that we have a common understanding of > what the proposal is about and its implications. > > > > Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ? I don't understand the intent of the question too well - but on the server side it seems cheap. > Q1.5: Is the cost of Ping caused by it being the first/second option to be > standardized or will we have to suffer the same cost when options > are > added in the future ? What cost? > > Q2: Does ENDS0 Ping offer additional protection to > "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSSEC" ? I'm not sure, but may be some benefit to both. It's a useful function, standardizing useful functions is sensible for a standards body, even if the precise benefits are not clear. > Q3: Are the benefits of ENDS0 Ping realized incrementally with deployment > or > only when the majority of code bases are deployed? It's not clear, but there can be incremental benefits. > Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or the > producer? I don't think this can be easily answered in general. > Q4: Will ENDS0 Ping delay/prevent DNSSEC deployment? (explain) No, I don't think so. DNSSEC has certain advantages, and complex costs, but it's deployment is related more to complex political and security questions. > Q5: Does ENDS0 Ping expose any new security risks? No, but there could be performance risks. However the upgrade process will be gradual, so the risk is not excessive. > Q6: Do you support that the WG adopt the document ? Yes. Even if DNSSEC is adopted ( which is not certain ), plain DNS will continue to be used for a long time. The proposal increases the options for securing plain DNS over time. > If your answer is NO is there any other mechanism you want considered ? > Yes assumes you are willing to review future versions of the document. > > > Note: We have not asked any questions on the details on how the > option is implemented as that can be addressed after a > consensus on that EDNS0 is beneficial has been reached. > > Note: Just like EDNS0 discovery is unreliable when dealing with any cast > clusters, EDNS Ping discovery will be unreliable during time it takes to > upgrade > the whole cluster in all locations. This on its own is not an acceptable > argument > against this particular proposal. > > Olafur for the chairs > > [1] Implementation costs, State discovery, State Maintenance, deployment > cost, > operational cost etc. > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-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 Apr 23 02:56:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32843A71BD; Thu, 23 Apr 2009 02:56:43 -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 Kp9xYnK4jO2l; Thu, 23 Apr 2009 02:56:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C78713A6F01; Thu, 23 Apr 2009 02:56:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwvcA-000P1G-GM for namedroppers-data0@psg.com; Thu, 23 Apr 2009 09:53:06 +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 1Lwvbu-000Ozu-8j for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 09:52:58 +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.3/8.14.3) with ESMTP id n3N9qkb1092872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 11:52:46 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <49F03A6E.8080504@nlnetlabs.nl> Date: Thu, 23 Apr 2009 11:52:46 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: namedroppers@ops.ietf.org CC: Stephane Bortzmeyer , Aki Tuomi Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> In-Reply-To: <20090423083149.GA17599@nic.fr> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 23 Apr 2009 11:52:46 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Bortzmeyer wrote: >> I think any solution suffers from this drawback, not just EDNS0 PING. > Not a big deal, IMHO, the increased channel security is worth it, but > it is something to keep in mind. Hi, Looking at this proposal as an implementor, I have to have answers from the working group to questions (below) if this draft is standards-track. If the working group can answer them (in this draft or in others), then the EDNS0 PING approach could be worth it, and then I support the group working on EDNS0 PING. *[Probe] How do you probe for support of the EDNS0 PING option? Tell me about error returns, dropped messages, option ignored, option disables EDNS0 (but not further query) processing, timeouts... *[Fallback] How do you fallback? When the probe is not successful, how do you fallback in a secure, non-antisocial manner. *[Interop] What fallback method(s) should be implemented? If a resolvercluster is using different fallback implementations, they can get different answers, and thus start giving different answers to the same query. Interoperability problems between resolvers. *[Downgrade] Is the group convinced that there is no downgrade attack? *[State] The result of the probe, how to keep it around? What is the TTL of that state? When do you re-probe? Is the resolver fully vulnerably when starting up? What is the cache policy for the state, i.e. when cache memory is full and new probes are done, what domains are made insecure? Thus, the idea of making the ID field longer is attractively simple. The draft is not that simple, because it does not actually make the ID field longer, but uses an EDNS0 option. The EDNS0 PING idea as written down here, in my opinion, works only in good weather. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknwOm4ACgkQkDLqNwOhpPjRvQCfUGguJQBZ4wiYAYvjWlpQuUUi 774An3lqFmI7wQC3rOQ8p9A7n63Bj98m =fc7z -----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 Thu Apr 23 03:37:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0AF3A6FC0; Thu, 23 Apr 2009 03:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.624 X-Spam-Level: ** X-Spam-Status: No, score=2.624 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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-cXzYIkbV3D; Thu, 23 Apr 2009 03:37:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B7483A6D63; Thu, 23 Apr 2009 03:37:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwwEa-0002nE-Fo for namedroppers-data0@psg.com; Thu, 23 Apr 2009 10:32:48 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwwE1-0002hz-Ox for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 10:32:24 +0000 Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1LwwDw-0002QJ-UO; Thu, 23 Apr 2009 11:32:08 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1LwwDw-0005Yc-0C; Thu, 23 Apr 2009 11:32:08 +0100 Message-ID: From: "George Barwood" To: "W.C.A. Wijngaards" , Cc: "Stephane Bortzmeyer" , "Aki Tuomi" References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <49F03A6E.8080504@nlnetlabs.nl> Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 11:32:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "W.C.A. Wijngaards" To: Cc: "Stephane Bortzmeyer" ; "Aki Tuomi" Sent: Thursday, April 23, 2009 10:52 AM Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stephane Bortzmeyer wrote: >>> I think any solution suffers from this drawback, not just EDNS0 PING. >> Not a big deal, IMHO, the increased channel security is worth it, but >> it is something to keep in mind. > > Hi, > > Looking at this proposal as an implementor, I have to have answers from > the working group to questions (below) if this draft is standards-track. > If the working group can answer them (in this draft or in others), then > the EDNS0 PING approach could be worth it, and then I support the group > working on EDNS0 PING. > > *[Probe] How do you probe for support of the EDNS0 PING option? Tell > me about error returns, dropped messages, option ignored, option > disables EDNS0 (but not further query) processing, timeouts... The full set of responses by non-upgraded servers will have to be determined by experiment. I think most will return an error. > *[Fallback] How do you fallback? When the probe is not successful, how > do you fallback in a secure, non-antisocial manner. Up to the client - many strategies on the client side are possible. It might only be used when non-deterministic responses are observed. I don't think the standard needs to specify all possible uses, or what strategies a resolver should employ ( this might be a useful information document, but should not be a reason to hold up the standard ). > *[Interop] What fallback method(s) should be implemented? If a > resolvercluster is using different fallback implementations, they can > get different answers, and thus start giving different answers to the > same query. Interoperability problems between resolvers. Again, up to the implementor, not the primary concern for a standards body. > *[Downgrade] Is the group convinced that there is no downgrade attack? Depends on the fallback strategy in the client. Again, up to the implementor. > *[State] The result of the probe, how to keep it around? What is the > TTL of that state? When do you re-probe? Is the resolver fully > vulnerably when starting up? What is the cache policy for the state, > i.e. when cache memory is full and new probes are done, what domains are > made insecure? A normal position for a general purpose client would be to insist that all results are secure against out-of-path attacks. This requires extra queries, which has some performance implications that EDNS ping solves ( when deployed on the server side ). > Thus, the idea of making the ID field longer is attractively simple. > The draft is not that simple, because it does not actually make the ID > field longer, but uses an EDNS0 option. The EDNS0 PING idea as written > down here, in my opinion, works only in good weather. It is not a panacea, but provides an option that may be useful, especially for high performance non-deterministic authorities, where optaining secure results is otherwise difficult/expensive in term of packets required. It may also be useful for securing the hop between a stub resolver and the recursive resolver. My view is that it is sensible, we may not be able to forsee the benefits ( which may take many years to materialise ), but it is worth trying nevertheless. Regards, George > Best regards, > Wouter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAknwOm4ACgkQkDLqNwOhpPjRvQCfUGguJQBZ4wiYAYvjWlpQuUUi > 774An3lqFmI7wQC3rOQ8p9A7n63Bj98m > =fc7z > -----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: > -- to unsubscribe send a message to namedroppers-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 Apr 23 04:11:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50B03A7266; Thu, 23 Apr 2009 04:11:48 -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 oHdELw2LnxIZ; Thu, 23 Apr 2009 04:11:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2DB5928C0DD; Thu, 23 Apr 2009 04:11:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwwnI-0007FQ-9U for namedroppers-data0@psg.com; Thu, 23 Apr 2009 11:08:40 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwwmy-0007Bl-5Z for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 11:08:26 +0000 Received: from guava.gson.org (a91-152-93-245.elisa-laajakaista.fi [91.152.93.245]) by gurgel.gson.org (Postfix) with ESMTP id 8F8217C422; Thu, 23 Apr 2009 11:08:18 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 9937875F44; Thu, 23 Apr 2009 14:08:17 +0300 (EEST) Message-ID: <18928.19486.19907.220570@guava.gson.org> Date: Thu, 23 Apr 2009 14:08:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "W.C.A. Wijngaards" Cc: namedroppers@ops.ietf.org, Stephane Bortzmeyer , Aki Tuomi Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? In-Reply-To: <49F03A6E.8080504@nlnetlabs.nl> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <49F03A6E.8080504@nlnetlabs.nl> 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: W.C.A. Wijngaards wrote: > Looking at this proposal as an implementor, I have to have answers from > the working group to questions (below) if this draft is standards-track. > If the working group can answer them (in this draft or in others), then > the EDNS0 PING approach could be worth it, and then I support the group > working on EDNS0 PING. That's funny, because looking at this proposal as a (former) server implementor, I would actually prefer the opposite, that the working group _not_ get into such details as a prerequisite to standardizing the PING option itself. There is a myriad possible designs for how a resolver might handle probing, fallback, downgrade attacks, state, etc. There is probably more than one good design (and many more bad ones). Implementors should be free to explore this design space and compete in making the best possible use of the PING option (or not, if they so choose); that will be far more effective than trying to come up with a single design by committee, and it can be done in parallel with the roll-out of the PING option on the authoritative server side. -- 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 Thu Apr 23 04:12:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2933A67EC; Thu, 23 Apr 2009 04:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=0.250, 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 TPMJ3to9Sryl; Thu, 23 Apr 2009 04:12:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D32C63A6814; Thu, 23 Apr 2009 04:12:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwwpt-0007bO-8N for namedroppers-data0@psg.com; Thu, 23 Apr 2009 11:11:21 +0000 Received: from [194.100.2.122] (helo=smtp2.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwwpb-0007Yw-KZ for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 11:11:14 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp2.tdc.fi (Postfix) with ESMTP id 7822E6ADAD7 for ; Thu, 23 Apr 2009 14:10:50 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 14:10:24 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F13F27B50@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Thread-Index: AcnEA9KG88LfGhG6RhWIFWHoffBKzwAACZrg References: <200904221507.n3MF7G6J047453@stora.ogud.com><49EF5FC2.3070007@nic.at><20090423072539.GC6975@nic.fr><86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net><20090423083149.GA17599@nic.fr><49F03A6E.8080504@nlnetlabs.nl> <18928.19486.19907.220570@guava.gson.org> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFuZHJlYXMgR3VzdGFmc3Nv biBbbWFpbHRvOmdzb25AYXJhbmV1cy5maV0NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDIzLCAy MDA5IDI6MDggUE0NCj4gVG86IFcuQy5BLiBXaWpuZ2FhcmRzDQo+IENjOiBuYW1lZHJvcHBlcnNA b3BzLmlldGYub3JnOyBTdGVwaGFuZSBCb3J0em1leWVyOyBBa2kgVHVvbWkNCj4gU3ViamVjdDog UmU6IFtkbnNleHRdIFJlOiBBZG9wdCBFRE5TMCBQaW5nLCBiZW5lZml0cyB2cyBkaXNhZHZhbnRh Z2VzID8NCj4gDQo+IFcuQy5BLiBXaWpuZ2FhcmRzIHdyb3RlOg0KPiA+IExvb2tpbmcgYXQgdGhp cyBwcm9wb3NhbCBhcyBhbiBpbXBsZW1lbnRvciwgSSBoYXZlIHRvIGhhdmUgYW5zd2Vycw0KPiBm cm9tDQo+ID4gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcXVlc3Rpb25zIChiZWxvdykgaWYgdGhpcyBk cmFmdCBpcyBzdGFuZGFyZHMtDQo+IHRyYWNrLg0KPiA+ICBJZiB0aGUgd29ya2luZyBncm91cCBj YW4gYW5zd2VyIHRoZW0gKGluIHRoaXMgZHJhZnQgb3IgaW4gb3RoZXJzKSwNCj4gdGhlbg0KPiA+ IHRoZSBFRE5TMCBQSU5HIGFwcHJvYWNoIGNvdWxkIGJlIHdvcnRoIGl0LCBhbmQgdGhlbiBJIHN1 cHBvcnQgdGhlDQo+IGdyb3VwDQo+ID4gd29ya2luZyBvbiBFRE5TMCBQSU5HLg0KPiANCj4gVGhh dCdzIGZ1bm55LCBiZWNhdXNlIGxvb2tpbmcgYXQgdGhpcyBwcm9wb3NhbCBhcyBhIChmb3JtZXIp IHNlcnZlcg0KPiBpbXBsZW1lbnRvciwgSSB3b3VsZCBhY3R1YWxseSBwcmVmZXIgdGhlIG9wcG9z aXRlLCB0aGF0IHRoZSB3b3JraW5nDQo+IGdyb3VwIF9ub3RfIGdldCBpbnRvIHN1Y2ggZGV0YWls cyBhcyBhIHByZXJlcXVpc2l0ZSB0byBzdGFuZGFyZGl6aW5nDQo+IHRoZSBQSU5HIG9wdGlvbiBp dHNlbGYuDQo+IA0KPiBUaGVyZSBpcyBhIG15cmlhZCBwb3NzaWJsZSBkZXNpZ25zIGZvciBob3cg YSByZXNvbHZlciBtaWdodCBoYW5kbGUNCj4gcHJvYmluZywgZmFsbGJhY2ssIGRvd25ncmFkZSBh dHRhY2tzLCBzdGF0ZSwgZXRjLiAgVGhlcmUgaXMgcHJvYmFibHkNCj4gbW9yZSB0aGFuIG9uZSBn b29kIGRlc2lnbiAoYW5kIG1hbnkgbW9yZSBiYWQgb25lcykuICBJbXBsZW1lbnRvcnMNCj4gc2hv dWxkIGJlIGZyZWUgdG8gZXhwbG9yZSB0aGlzIGRlc2lnbiBzcGFjZSBhbmQgY29tcGV0ZSBpbiBt YWtpbmcgdGhlDQo+IGJlc3QgcG9zc2libGUgdXNlIG9mIHRoZSBQSU5HIG9wdGlvbiAob3Igbm90 LCBpZiB0aGV5IHNvIGNob29zZSk7IHRoYXQNCj4gd2lsbCBiZSBmYXIgbW9yZSBlZmZlY3RpdmUg dGhhbiB0cnlpbmcgdG8gY29tZSB1cCB3aXRoIGEgc2luZ2xlIGRlc2lnbg0KPiBieSBjb21taXR0 ZWUsIGFuZCBpdCBjYW4gYmUgZG9uZSBpbiBwYXJhbGxlbCB3aXRoIHRoZSByb2xsLW91dCBvZiB0 aGUNCj4gUElORyBvcHRpb24gb24gdGhlIGF1dGhvcml0YXRpdmUgc2VydmVyIHNpZGUuDQo+IC0t DQo+IEFuZHJlYXMgR3VzdGFmc3NvbiwgZ3NvbkBhcmFuZXVzLmZpDQoNCkkgc3VwcG9zZSBPUHMg cXVlc3Rpb24gY291bGQgYmUgdmlld2VkIGFzICJyZWZlcmVuY2UiIG9yICJleGFtcGxlIiBpbXBs ZW1lbnRhdGlvbiB0byBnaXZlIGluc2lnaHQgb2YgcHJhY3RpY2FsIGltcGxpY2F0aW9ucywgaW5z dGVhZCBvZiBhcyBzb21ldGhpbmcgcGVvcGxlIHNob3VsZCBzdGFuZGFyZGl6ZS4gDQoNCi0tLQ0K QWtpIFR1b21pDQpUREMgT3kNCg0K -- to unsubscribe send a message to namedroppers-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 Apr 23 05:42:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B2F3A69F8; Thu, 23 Apr 2009 05:42:38 -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 NBdDIXFQzPNx; Thu, 23 Apr 2009 05:42:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 453403A6C6A; Thu, 23 Apr 2009 05:42:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwyBk-000HZY-PQ for namedroppers-data0@psg.com; Thu, 23 Apr 2009 12:38:00 +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 1LwyBW-000HY6-LE for namedroppers@psg.com; Thu, 23 Apr 2009 12:37:52 +0000 Received: from [IPv6:2001:7b8:206:1:223:54ff:fe09:d688] ([IPv6:2001:7b8:206:1:223:54ff:fe09:d688]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n3NCbd00010472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 14:37:40 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <49F06113.6060705@NLnetLabs.nl> Date: Thu, 23 Apr 2009 14:37:39 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Hoffman CC: Florian Weimer , namedroppers@psg.com Subject: Re: [dnsext] Contradictions in NSEC3 wording in draft-ietf-dnsext-dnssec-rsasha256 References: <82ocuqm7uv.fsf@mid.bfk.de> <49EDD540.300@NLnetLabs.nl> <828wlum67o.fsf@mid.bfk.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 23 Apr 2009 14:37:43 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Hoffman wrote: >>>> >>> that would mean treating part of a signed zone different than the rest >>> of it... so no. >> Then you should write "validate", I think. > > That works for me. > I have heard no other plusses or minuses, and I like the text, so I'll submit an update shortly. There will also be another addition as a gift from your editor. 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: From owner-namedroppers@ops.ietf.org Thu Apr 23 05:53:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1B73A6E7D; Thu, 23 Apr 2009 05:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.153 X-Spam-Level: X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=-2.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_HTML_URI_LHOST31=1.666] 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 nSUhtbxxAa5v; Thu, 23 Apr 2009 05:53:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 892A73A694D; Thu, 23 Apr 2009 05:53:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwyOP-000JOv-IC for namedroppers-data0@psg.com; Thu, 23 Apr 2009 12:51:05 +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 1LwyOB-000JNW-7H for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 12:50:58 +0000 Message-ID: <49F06426.4000702@ca.afilias.info> Date: Thu, 23 Apr 2009 14:50:46 +0200 From: Shane Kerr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Aki Tuomi CC: namedroppers@ops.ietf.org Subject: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> In-Reply-To: <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Aki, Aki Tuomi wrote: >> -----Original Message----- >> From: owner-namedroppers@ops.ietf.org [mailto:owner- >> namedroppers@ops.ietf.org] On Behalf Of Stephane Bortzmeyer >> Sent: Thursday, April 23, 2009 10:26 AM >> To: Otmar Lendl >> Cc: namedroppers@ops.ietf.org >> Subject: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? >> >> On Wed, Apr 22, 2009 at 08:19:46PM +0200, >> Otmar Lendl wrote >> a message of 70 lines which said: >> >>> The cost varies between the authoritative server and the resolver. >>> >>> IMHO (and this is without having looked at the code), the server-side >> is >>> rather trivial. No state. Just echo that record back. >> There is another cost for the authoritative server which did not >> upgrade to edns-ping: an increase in the number of queries by >> edns-ping resolvers trying to find out if there was a downgrade attack >> or if the authoritative server really does not support edns-ping. Not >> a big problem, IMHO, but it should be mentioned for completeness. >> >> > > I think any solution suffers from this drawback, not just EDNS0 PING. Not necessarily. One idea is registering what features a name server supports in the DNS(*). So, one could: * create a new RTYPE to encode which EDNS0 options were supported * create a new EDNS0 option which the parent server would use to report EDNS0 support from child records (as documented in the RTYPE) So, as the operator of TIME-TRAVELLERS.ORG, my zone might have: time-travellers.org. NS ns1.time-travellers.org. NS ns2.time-travellers.org. ns1.time-travellers.org A 1.2.3.4 EDNS0OPT ( NSID PING ) ns2.time-travellers.org A 2.3.4.5 EDNS0OPT ( NSID PING ) The EDNS0OPT would be a new type of glue. -- Shane (*) This idea occurs to me after looking at DNSCurve. DNScurve encodes a public key in the NS set for a zone. So your NS set may be: example.com NS d4fdfsu8j3j331234faes32aaasdfGG.example.com NS lkj4444lkjsadfo89unasdfnasdlqu1.example.com A clever idea, and one that can be extended here. -- to unsubscribe send a message to namedroppers-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 Apr 23 06:10:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B0F28C21F; Thu, 23 Apr 2009 06:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-1.696, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_43=0.6, MIME_ASCII0=1.5, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_HTML_URI_LHOST31=1.666] 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 qyVzEhjgtzch; Thu, 23 Apr 2009 06:10:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 50B983A6F82; Thu, 23 Apr 2009 06:07:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwybA-000LPm-Px for namedroppers-data0@psg.com; Thu, 23 Apr 2009 13:04:16 +0000 Received: from [194.100.2.122] (helo=smtp2.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwyan-000LKV-Gj for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 13:04:00 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp2.tdc.fi (Postfix) with ESMTP id 298BA6B28D0 for ; Thu, 23 Apr 2009 16:03:49 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 15:56:12 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F13F27B52@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Thread-Index: AcnEEiZ+VOUHI3nIRfikSH/wSIduzgAAI1zA References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaGFuZSBLZXJyIFttYWlsdG86 c2hhbmVAY2EuYWZpbGlhcy5pbmZvXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMDkg Mzo1MSBQTQ0KPiBUbzogQWtpIFR1b21pDQo+IENjOiBuYW1lZHJvcHBlcnNAb3BzLmlldGYub3Jn DQo+IFN1YmplY3Q6IFB1Ymxpc2hpbmcgTlMgZmVhdHVyZXMgaW4gdGhlIEROUywgd2FzIFJlOiBb ZG5zZXh0XSBSZTogQWRvcHQNCj4gRUROUzAgUGluZywgYmVuZWZpdHMgdnMgZGlzYWR2YW50YWdl cyA/DQo+IA0KPiBBa2ksDQo+IA0KPiBBa2kgVHVvbWkgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG93bmVyLW5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5v cmcgW21haWx0bzpvd25lci0NCj4gPj4gbmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZ10gT24gQmVo YWxmIE9mIFN0ZXBoYW5lIEJvcnR6bWV5ZXINCj4gPj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDIz LCAyMDA5IDEwOjI2IEFNDQo+ID4+IFRvOiBPdG1hciBMZW5kbA0KPiA+PiBDYzogbmFtZWRyb3Bw ZXJzQG9wcy5pZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbZG5zZXh0XSBSZTogQWRvcHQgRUROUzAg UGluZywgYmVuZWZpdHMgdnMgZGlzYWR2YW50YWdlcyA/DQo+ID4+DQo+ID4+IE9uIFdlZCwgQXBy IDIyLCAyMDA5IGF0IDA4OjE5OjQ2UE0gKzAyMDAsDQo+ID4+ICBPdG1hciBMZW5kbCA8bGVuZGxA bmljLmF0PiB3cm90ZQ0KPiA+PiAgYSBtZXNzYWdlIG9mIDcwIGxpbmVzIHdoaWNoIHNhaWQ6DQo+ ID4+DQo+ID4+PiBUaGUgY29zdCB2YXJpZXMgYmV0d2VlbiB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2 ZXIgYW5kIHRoZSByZXNvbHZlci4NCj4gPj4+DQo+ID4+PiBJTUhPIChhbmQgdGhpcyBpcyB3aXRo b3V0IGhhdmluZyBsb29rZWQgYXQgdGhlIGNvZGUpLCB0aGUgc2VydmVyLQ0KPiBzaWRlDQo+ID4+ IGlzDQo+ID4+PiByYXRoZXIgdHJpdmlhbC4gTm8gc3RhdGUuIEp1c3QgZWNobyB0aGF0IHJlY29y ZCBiYWNrLg0KPiA+PiBUaGVyZSBpcyBhbm90aGVyIGNvc3QgZm9yIHRoZSBhdXRob3JpdGF0aXZl IHNlcnZlciB3aGljaCBkaWQgbm90DQo+ID4+IHVwZ3JhZGUgdG8gZWRucy1waW5nOiBhbiBpbmNy ZWFzZSBpbiB0aGUgbnVtYmVyIG9mIHF1ZXJpZXMgYnkNCj4gPj4gZWRucy1waW5nIHJlc29sdmVy cyB0cnlpbmcgdG8gZmluZCBvdXQgaWYgdGhlcmUgd2FzIGEgZG93bmdyYWRlDQo+IGF0dGFjaw0K PiA+PiBvciBpZiB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgcmVhbGx5IGRvZXMgbm90IHN1cHBv cnQgZWRucy1waW5nLg0KPiBOb3QNCj4gPj4gYSBiaWcgcHJvYmxlbSwgSU1ITywgYnV0IGl0IHNo b3VsZCBiZSBtZW50aW9uZWQgZm9yIGNvbXBsZXRlbmVzcy4NCj4gPj4NCj4gPj4NCj4gPg0KPiA+ IEkgdGhpbmsgYW55IHNvbHV0aW9uIHN1ZmZlcnMgZnJvbSB0aGlzIGRyYXdiYWNrLCBub3QganVz dCBFRE5TMCBQSU5HLg0KPiANCj4gTm90IG5lY2Vzc2FyaWx5Lg0KPiANCj4gT25lIGlkZWEgaXMg cmVnaXN0ZXJpbmcgd2hhdCBmZWF0dXJlcyBhIG5hbWUgc2VydmVyIHN1cHBvcnRzIGluIHRoZQ0K PiBETlMoKikuDQo+IA0KPiBTbywgb25lIGNvdWxkOg0KPiANCj4gKiBjcmVhdGUgYSBuZXcgUlRZ UEUgdG8gZW5jb2RlIHdoaWNoIEVETlMwIG9wdGlvbnMgd2VyZSBzdXBwb3J0ZWQNCj4gKiBjcmVh dGUgYSBuZXcgRUROUzAgb3B0aW9uIHdoaWNoIHRoZSBwYXJlbnQgc2VydmVyIHdvdWxkIHVzZSB0 bw0KPiAgIHJlcG9ydCBFRE5TMCBzdXBwb3J0IGZyb20gY2hpbGQgcmVjb3JkcyAoYXMgZG9jdW1l bnRlZCBpbiB0aGUgUlRZUEUpDQo+IA0KPiBTbywgYXMgdGhlIG9wZXJhdG9yIG9mIFRJTUUtVFJB VkVMTEVSUy5PUkcsIG15IHpvbmUgbWlnaHQgaGF2ZToNCj4gDQo+IHRpbWUtdHJhdmVsbGVycy5v cmcuICAgICBOUyAgICAgICAgbnMxLnRpbWUtdHJhdmVsbGVycy5vcmcuDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICBOUyAgICAgICAgbnMyLnRpbWUtdHJhdmVsbGVycy5vcmcuDQo+IG5zMS50 aW1lLXRyYXZlbGxlcnMub3JnICBBICAgICAgICAgMS4yLjMuNA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgRUROUzBPUFQgICggTlNJRCBQSU5HICkNCj4gbnMyLnRpbWUtdHJhdmVsbGVycy5v cmcgIEEgICAgICAgICAyLjMuNC41DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBFRE5TME9Q VCAgKCBOU0lEIFBJTkcgKQ0KPiANCj4gVGhlIEVETlMwT1BUIHdvdWxkIGJlIGEgbmV3IHR5cGUg b2YgZ2x1ZS4NCj4gDQo+IC0tDQo+IFNoYW5lDQo+IA0KPiAoKikgVGhpcyBpZGVhIG9jY3VycyB0 byBtZSBhZnRlciBsb29raW5nIGF0IEROU0N1cnZlLiBETlNjdXJ2ZSBlbmNvZGVzDQo+IGENCj4g cHVibGljIGtleSBpbiB0aGUgTlMgc2V0IGZvciBhIHpvbmUuIFNvIHlvdXIgTlMgc2V0IG1heSBi ZToNCj4gDQo+IGV4YW1wbGUuY29tIE5TIGQ0ZmRmc3U4ajNqMzMxMjM0ZmFlczMyYWFhc2RmR0cu ZXhhbXBsZS5jb20NCj4gICAgICAgICAgICAgTlMgbGtqNDQ0NGxranNhZGZvODl1bmFzZGZuYXNk bHF1MS5leGFtcGxlLmNvbQ0KPiANCj4gQSBjbGV2ZXIgaWRlYSwgYW5kIG9uZSB0aGF0IGNhbiBi ZSBleHRlbmRlZCBoZXJlLg0KDQpZZXMsIHdoaWNoIHJlcXVpcmVzIGV4dHJhIHJlcXVlc3RzLiBZ b3Ugc3RpbGwgaGF2ZSB0byAocGVyaW9kaWNhbGx5KSBxdWVyeSB0aGUgb3RoZXIgcGFydHkuIFBy b2JhYmx5IHF1aXRlIG9mdGVuLiBTbyB0aGVyZSBpcyBzdGlsbCBubyBmcmVlIGx1bmNoLiANCg0K LS0tDQpBa2kgVHVvbWkNClREQyBPeQ0KDQo= -- to unsubscribe send a message to namedroppers-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 Apr 23 06:10:54 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8DC3A6BF7; Thu, 23 Apr 2009 06:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.059 X-Spam-Level: X-Spam-Status: No, score=-4.059 tagged_above=-999 required=5 tests=[AWL=-1.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, J_CHICKENPOX_43=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 qcyCeR4LzMOc; Thu, 23 Apr 2009 06:10:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6113628C6BD; Thu, 23 Apr 2009 06:10:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwyez-000MI3-RY for namedroppers-data0@psg.com; Thu, 23 Apr 2009 13:08:13 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwyen-000MG4-3h; Thu, 23 Apr 2009 13:08:07 +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=j92j/Q2iz8znYpC0BGBa97TE4nSN6VZZRt+nPdgqBaX6T8Thk+PCiEkA PL4pXYzG9qwR42DrtKimcrajflr75SLA9ArecsZe4wxU6mEtY/ldEKxMy 0DtljkqtfMPiPRD; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1240492081; x=1272028081; 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:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20Publi shing=20NS=20features=20in=20the=20DNS,=20was=20Re:=20[dn sext]=20Re:=20Adopt=20EDNS0=0D=0A=20Ping,=20=20benefits =20vs=20disadvantages=20?|Date:=20Thu,=2023=20Apr=202009 =2014:07:56=20+0100|Message-ID:=20|To: =20Shane=20Kerr=20|Cc:=20Aki=20Tuo mi=20,=0D=0A=09namedroppers@ops.ietf.or g,=0D=0A=09owner-namedroppers@ops.ietf.org|MIME-Version: =201.0|In-Reply-To:=20<49F06426.4000702@ca.afilias.info> |References:=20<200904221507.n3MF7G6J047453@stora.ogud.co m>=09<49EF5FC2.3070007@nic.at>=20<20090423072539.GC6975@n ic.fr>=20<86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel 2ex01.nordiclan.net>=20<49F06426.4000702@ca.afilias.info>; bh=Vp92mol4hg3DGifrQsbSJezvjq3HJGlC7JvGx4iC64Y=; b=nh/YkMELCGGLZIx1QrHUZGUsxnuyHHm/nQx+4E4ysmPsjWdwbSdzjChL YKsrFBGqH85ciSZalcUJPQSKS5QNyIAsifFSoa5R+z3P2d49EKHTaiHhW vV4F86Et1gxTV+4; X-IronPort-AV: E=Sophos;i="4.40,235,1238972400"; d="scan'208";a="13246394" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Apr 2009 14:07:57 +0100 In-Reply-To: <49F06426.4000702@ca.afilias.info> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> To: Shane Kerr Cc: Aki Tuomi , namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 23 Apr 2009 14:07:56 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/04/2009 02:07:58 PM, Serialize complete at 23/04/2009 02:07:58 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > One idea is registering what features a name server supports in the DNS(*). > > So, one could: > > * create a new RTYPE to encode which EDNS0 options were supported > * create a new EDNS0 option which the parent server would use to > report EDNS0 support from child records (as documented in the RTYPE) > > So, as the operator of TIME-TRAVELLERS.ORG, my zone might have: > > time-travellers.org. NS ns1.time-travellers.org. > NS ns2.time-travellers.org. > ns1.time-travellers.org A 1.2.3.4 > EDNS0OPT ( NSID PING ) > ns2.time-travellers.org A 2.3.4.5 > EDNS0OPT ( NSID PING ) > > The EDNS0OPT would be a new type of glue. Although since EDNS0 is a hop-by-hop mechanism this would only protect the recursive -> authoritative path, and only if the recursor can guarantee that no intervening box will interfere with EDNS0's correct operation. Ray -- to unsubscribe send a message to namedroppers-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 Apr 23 06:24:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5EE03A71B7; Thu, 23 Apr 2009 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 01PwL-cs-zZN; Thu, 23 Apr 2009 06:24:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB0CC3A70CE; Thu, 23 Apr 2009 06:24:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwyrL-000Np3-OX for namedroppers-data0@psg.com; Thu, 23 Apr 2009 13:20:59 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwyr4-000Nn0-5b for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 13:20:53 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 69DB32FE9583 for ; Thu, 23 Apr 2009 13:20:38 +0000 (UTC) Date: Thu, 23 Apr 2009 09:20:36 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090423132036.GA68360@shinkuro.com> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: [no hat] On Wed, Apr 22, 2009 at 12:17:19PM -0700, Nicholas Weaver wrote: > If you want the benefits of DNSSEC, the stub, not the recursor, MUST be > the validator. Since the recursor is an untrustworthy part in DNSSEC. Only if you don't have a secure path to the recursor, of course. (I recognise that might be hard, however, in a DHCP environment.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 23 06:25:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D683A69F6; Thu, 23 Apr 2009 06:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=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 485buUNreypZ; Thu, 23 Apr 2009 06:25:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77EB53A63EB; Thu, 23 Apr 2009 06:25:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwyuS-000OGW-EH for namedroppers-data0@psg.com; Thu, 23 Apr 2009 13:24:12 +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 1LwyuC-000OEg-Mz for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 13:24:05 +0000 Message-ID: <49F06BE9.5020406@ca.afilias.info> Date: Thu, 23 Apr 2009 15:23:53 +0200 From: Shane Kerr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk CC: namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ray, Ray.Bellis@nominet.org.uk wrote: >> One idea is registering what features a name server supports in the > DNS(*). >> So, one could: >> >> * create a new RTYPE to encode which EDNS0 options were supported >> * create a new EDNS0 option which the parent server would use to >> report EDNS0 support from child records (as documented in the RTYPE) Oh, the child would also use this! The idea of using an EDNS0 option for this rather than a separate QUERY is that, like NSID, you want it to be part of a "normal" query. In the case of EDNS0OPT this would be something you want to do to avoid extra traffic. >> So, as the operator of TIME-TRAVELLERS.ORG, my zone might have: >> >> time-travellers.org. NS ns1.time-travellers.org. >> NS ns2.time-travellers.org. >> ns1.time-travellers.org A 1.2.3.4 >> EDNS0OPT ( NSID PING ) >> ns2.time-travellers.org A 2.3.4.5 >> EDNS0OPT ( NSID PING ) >> >> The EDNS0OPT would be a new type of glue. > > Although since EDNS0 is a hop-by-hop mechanism this would only protect the > recursive -> authoritative path, True, but that is probably the biggest target and concern. In fact, I never really considered any other! :) > and only if the recursor can guarantee > that no intervening box will interfere with EDNS0's correct operation. Well, kind of. This is the kind of details that would come out in a draft, but my expectation would be that EDNS0 would be an "upgrade" type option. So, if *any* responses get from a server to a resolver indicating the server has EDNS0 Ping support, then the resolver would cache that result (using normal TTL expiration mechanisms). -- 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 Thu Apr 23 06:26:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616233A69F6; Thu, 23 Apr 2009 06:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.537 X-Spam-Level: X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_43=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 4ed+NSY5HQAM; Thu, 23 Apr 2009 06:26:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 612363A6A78; Thu, 23 Apr 2009 06:26:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lwyvj-000OaJ-6A for namedroppers-data0@psg.com; Thu, 23 Apr 2009 13:25:31 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwyvW-000OXQ-DA for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 13:25:24 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1LwyvA-0005sy-Su; Thu, 23 Apr 2009 15:24:56 +0200 Received: from fweimer by bfk.de with local id 1LwyvS-0001n5-JV; Thu, 23 Apr 2009 15:25:14 +0200 To: Shane Kerr Cc: Aki Tuomi , namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> From: Florian Weimer Date: Thu, 23 Apr 2009 15:25:14 +0200 In-Reply-To: <49F06426.4000702@ca.afilias.info> (Shane Kerr's message of "Thu, 23 Apr 2009 14:50:46 +0200") Message-ID: <82hc0fa4ed.fsf@mid.bfk.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: * Shane Kerr: > So, one could: > > * create a new RTYPE to encode which EDNS0 options were supported > * create a new EDNS0 option which the parent server would use to > report EDNS0 support from child records (as documented in the RTYPE) > > So, as the operator of TIME-TRAVELLERS.ORG, my zone might have: > > time-travellers.org. NS ns1.time-travellers.org. > NS ns2.time-travellers.org. > ns1.time-travellers.org A 1.2.3.4 > EDNS0OPT ( NSID PING ) > ns2.time-travellers.org A 2.3.4.5 > EDNS0OPT ( NSID PING ) > > The EDNS0OPT would be a new type of glue. I think it's not really that much more work to put a DS record there instead of an EDNS0OPT record, so I don't think this approach offers a got trade-off. If you want signalling, you have to put it into the name, Dnscurve-style. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-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 Apr 23 06:31:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501E33A721E; Thu, 23 Apr 2009 06:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.384 X-Spam-Level: X-Spam-Status: No, score=-4.384 tagged_above=-999 required=5 tests=[AWL=-1.085, 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 v1VVAC-6GtqL; Thu, 23 Apr 2009 06:31:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4162A3A63EB; Thu, 23 Apr 2009 06:31:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwyyY-000P66-Uc for namedroppers-data0@psg.com; Thu, 23 Apr 2009 13:28:26 +0000 Received: from [131.111.8.135] (helo=ppsw-5.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwyyG-000P2e-Fd for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 13:28:20 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35942) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1LwyyF-0006VE-HV (Exim 4.70) (return-path ); Thu, 23 Apr 2009 14:28:07 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LwyyF-0004X5-DB (Exim 4.67) (return-path ); Thu, 23 Apr 2009 14:28:07 +0100 Date: Thu, 23 Apr 2009 14:28:07 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Stuart Cheshire cc: IETF DNSEXT WG Subject: Re: [dnsext] "Network bit order" in RFC 3845 In-Reply-To: <2EF3EE9C-31EF-4964-AD21-AF06D19DD450@apple.com> Message-ID: References: <2EF3EE9C-31EF-4964-AD21-AF06D19DD450@apple.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, 22 Apr 2009, Stuart Cheshire wrote: > RFC 3845 says: > > Each bitmap encodes the low-order 8 bits of RR types within the > window block, in network bit order. The first bit is bit 0. > > What the hell does that mean? I would argue it's meaningless. The Internet is an octet transport medium and the order of the bits within the octet is invisible. For example, Token Ring sends bytes in little endian bit order, whereas serial Ethernet uses big endian bit order, and gigabit Ethernet over copper sends bytes in parallel. Numbering of bits is orthogonal to transmission order. RFC 3845 should have said "leftmost, most significant bit" instead of "first bit" and noted that this is consistent with network byte ordering. See also the numbering of bits in the packet diagrams in RFC 793 etc. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-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 Apr 23 07:02:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC273A6A47; Thu, 23 Apr 2009 07:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 8RCaz-1dMH9b; Thu, 23 Apr 2009 07:02:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07FAE3A69B4; Thu, 23 Apr 2009 07:02:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwzQG-0003K9-Ge for namedroppers-data0@psg.com; Thu, 23 Apr 2009 13:57:04 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwzQ4-0003IX-Dj for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 13:56:58 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C73742FE9583 for ; Thu, 23 Apr 2009 13:56:50 +0000 (UTC) Date: Thu, 23 Apr 2009 09:56:49 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] "Network bit order" in RFC 3845 Message-ID: <20090423135649.GB68521@shinkuro.com> References: <2EF3EE9C-31EF-4964-AD21-AF06D19DD450@apple.com> <1028365c0904221726i7b045d89k840fc15273cb52ac@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1028365c0904221726i7b045d89k840fc15273cb52ac@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Wed, Apr 22, 2009 at 08:26:12PM -0400, Donald Eastlake wrote: > You wanted to look up "network order" which is mentioned in many RFCs > starting at least as early as RFC 1235. Is this a clarification that ought to be made with, say, an erratum? (That's not a suggestion, it's a question.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 23 07:32:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA0E3A727F; Thu, 23 Apr 2009 07:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.104 X-Spam-Level: X-Spam-Status: No, score=-5.104 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_101=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 oR1qxHJhUiKP; Thu, 23 Apr 2009 07:32:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53F583A71C8; Thu, 23 Apr 2009 07:32:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwzvX-0006wA-2p for namedroppers-data0@psg.com; Thu, 23 Apr 2009 14:29:23 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwzvK-0006vP-Gk for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 14:29:16 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3NET5dD012284; Thu, 23 Apr 2009 07:29:05 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Andrew Sullivan In-Reply-To: <20090423132036.GA68360@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 07:29:05 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 6:20 AM, Andrew Sullivan wrote: > [no hat] > > On Wed, Apr 22, 2009 at 12:17:19PM -0700, Nicholas Weaver wrote: > >> If you want the benefits of DNSSEC, the stub, not the recursor, >> MUST be >> the validator. Since the recursor is an untrustworthy part in >> DNSSEC. > > Only if you don't have a secure path to the recursor, of course. (I > recognise that might be hard, however, in a DHCP environment.) No. The recursor itself IS the untrustworthy part! OpenDNS: [gala:~/archive/svn_nweaver/presentation] nweaver% dig www.google.com @208.67.222.222 ... ;; ANSWER SECTION: www.google.com. 30 IN CNAME google.navigation.opendns.com. google.navigation.opendns.com. 30 IN A 208.67.219.231 google.navigation.opendns.com. 30 IN A 208.67.219.230 Malicious Recursive Resolver (DNSchanger malcode): [gala:~/archive/svn_nweaver/presentation] nweaver% dig ad.doubleclick.net @85.255.112.122 ;; ANSWER SECTION: ad.doubleclick.net. 26 IN A 93.190.141.162 [gala:~/archive/svn_nweaver/presentation] nweaver% dig -x 93.190.141.162 ;; QUESTION SECTION: ;162.141.190.93.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 141.190.93.in-addr.arpa. 3600 IN SOA ns1.worldstream.nl. hostmaster.w orldstream.nl. 2009041900 10800 3600 604800 3600 This is why I mean "the recursive resolver is the only substantial in- path adversary for DNS traffic thats not in-path for the final application". And why the stub, not the recursive resolver, MUST be the one to validate DNSSEC information, and why, on validation failure, I believe the stub should generate its own request, bypassing the recursive resolver completely, and accept that result, as the default behavior for the existing gethostbyname() API. -- to unsubscribe send a message to namedroppers-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 Apr 23 07:53:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462723A7231; Thu, 23 Apr 2009 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 tmDW67wBdz8f; Thu, 23 Apr 2009 07:53:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BA733A72BB; Thu, 23 Apr 2009 07:53:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx0GG-0009Ki-Fn for namedroppers-data0@psg.com; Thu, 23 Apr 2009 14:50:48 +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 1Lx0G3-0009Jg-JJ for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 14:50:41 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3NEoXcw076129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 07:50:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090423135649.GB68521@shinkuro.com> References: <2EF3EE9C-31EF-4964-AD21-AF06D19DD450@apple.com> <1028365c0904221726i7b045d89k840fc15273cb52ac@mail.gmail.com> <20090423135649.GB68521@shinkuro.com> Date: Thu, 23 Apr 2009 07:50:33 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] "Network bit order" in RFC 3845 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:56 AM -0400 4/23/09, Andrew Sullivan wrote: >On Wed, Apr 22, 2009 at 08:26:12PM -0400, Donald Eastlake wrote: >> You wanted to look up "network order" which is mentioned in many RFCs >> starting at least as early as RFC 1235. > >Is this a clarification that ought to be made with, say, an erratum? >(That's not a suggestion, it's a question.) Yes, definitely. --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 Apr 23 08:07:49 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60493A67F0; Thu, 23 Apr 2009 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, 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 TvUruB-euc91; Thu, 23 Apr 2009 08:07:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E98B93A6C84; Thu, 23 Apr 2009 08:07:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx0TC-000BGe-Ho for namedroppers-data0@psg.com; Thu, 23 Apr 2009 15:04:10 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx0Sy-000BF2-LJ for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 15:04:03 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 226C5A1049; Thu, 23 Apr 2009 15:03:51 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Stephane Bortzmeyer cc: Aki Tuomi , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? In-Reply-To: Your message of "Thu, 23 Apr 2009 10:31:49 +0200." <20090423083149.GA17599@nic.fr> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 23 Apr 2009 15:03:51 +0000 Message-ID: <17616.1240499031@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Thu, 23 Apr 2009 10:31:49 +0200 > From: Stephane Bortzmeyer > > On Thu, Apr 23, 2009 at 11:01:22AM +0300, > Aki Tuomi wrote > a message of 33 lines which said: > > > I think any solution suffers from this drawback, not just EDNS0 PING. > > Before Paul Vixie steps in, I can quote his reasoning: with 0x20, > today, the majority of name servers is already compliant and will not > suffer for the increase of queries. With cookies or edns-ping, today, > the majority of name servers is not compliant. thanks for correctly channeling my spirit. the other reasons i don't support adoption of cookies or edns-ping are: it adds a lot of complexity in order to solve a problem that we're not having (hop by hop corruption) while failing to solve a problem we are having (end to end corruption); and, it changes the edns protocol due to an inherent downgrade attack. but as to the matter of extra packets: > Not a big deal, IMHO, the increased channel security is worth it, but > it is something to keep in mind. it is a VERY BIG deal. am i the only one here to groks the size of the installed base? changes we make to the hop-by-hop are amplified by the number of endpoints. channeling bob halley: "ok, it works in the lab, now multiply all your numbers by six million." except here it's 600 million. -- to unsubscribe send a message to namedroppers-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 Apr 23 08:22:58 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D8D3A6C8C; Thu, 23 Apr 2009 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.085 X-Spam-Level: X-Spam-Status: No, score=-5.085 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_74=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 zmo4Nb3e8NAy; Thu, 23 Apr 2009 08:22:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEA223A6928; Thu, 23 Apr 2009 08:22:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx0iF-000DIO-UK for namedroppers-data0@psg.com; Thu, 23 Apr 2009 15:19:43 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx0i1-000DG1-N1 for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 15:19:37 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3NFJS87017929; Thu, 23 Apr 2009 08:19:28 -0700 (PDT) Message-Id: From: Nicholas Weaver To: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: [dnsext] Thinking about a DNSSEC api... Date: Thu, 23 Apr 2009 08:19:28 -0700 Cc: Nicholas Weaver X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On the DNSSEC adoption front, my views have been pretty clear. One of the items I believe is necessary is a better API for applications, since thats where I believe the true value of DNSSEC lies. So here are my thoughts. Comments? Suggestions? rootoftrust management: An individual application can add/change/remove the roots of trust that the DNSSEC API will use. Such changes ONLY apply to the individual application. Roots of trust are specified by key and root domain. There needs to be a reasonable default root of trust here. gethostbyname() -> IP Address: This, from the application viewpoint, operates unchanged with DNSSEC enabled on the end host. There are a few differences on the back-end however: 1) The stub resolver/API will ONLY cache data which it can validate the DNSSEC signatures. 2) On ANY DNSSEC failure, INCLUDING an absence of DNSSEC information, the local stub resolver generates an independent iterative request, using only its OWN (DNSSEC-validated) cache, and bypassing the recursive resolver completely for any data it can't validate the DNSSEC signature for. For such requests, it will first contact the recursive resolver going up the heirarchy, taking the first result that it CAN validate the signature on. But otherwise, it will conduct its own independent iterative query, bypassing the recursive resolver completely. Why this policy? Because it actually offers substantial protection for existing applications using gethostbyname(): a) The applications are protected against all out-of-path attacks on any cache, regardless of the state of the caches and their implementation. b) If the API/stub resolver does proper port randomization and 0x20, the applications are protected against all out-of-path attacks on the transaction with very high confidence. c) The applications are protected against all malicious behavior from the recursive resolver, the one significant in-path attacker for DNS thats not in-path for the final application. Simply put, effectively all applications using gethostbyname() either don't rely on the name (because its end-to-end crypto and changes to the name->addr mapping are no different than an in-path adversary) or are trivially vulnerable to in-path adversaries. Thus the latter gain protection against the one in-path for DNS adversary thats not in-path for the final application, as well as complete protection against out- of-path adversaries. The (dis)advantage is anyone NOT using DNSSEC on their authority side is going to get slammed. If a major OS changes its API to use this scheme, it should use a random "cooking the frog" deployment: For the default user (no explicit selection), there is initially a 0% chance, rising to 100% chance over a one year period, to give authorities and recursive resolvers time to adapt. gethostbynamesecure(name) -> (IP ADDR, error status) This ONLY returns an IP address if the DNSSEC signature can be completely validated, OTHERWISE it returns the reason for the error (unknown root of trust, expired key (and where in the chain), no DNSSEC information, etc). (almost) useless, but included for completeness. getkeybynamesecure(host, service) -> (block of opaque bytes, error status) This does a lookup for the NULL RDATA information for service.host, verifying the DNSSEC signature and returning the bytes or the error status. This provides a generic mechanism for storing cryptographically- verified, service specific material in DNS. Thus applications can use this as an application-defined convention to look up various important features. EG, tls.www.example.com -> the SHA256-sum of the TLS certificate for the server ssh.login.example.com -> the SSH fingerprint. ipsec.example.com -> An IPSec public key for ALL IP communication This has a huge advantage over schemes like, say RFC 4255 in that it does not require changes to the DNS protocol or authority code to add applications/extend features, but it allows ANY application to have a cryptographically verified name->key mapping that is application specific. Additionally, one could easily have the authority forward the final request for service.host to the host itself, which means the authorities themselves don't need to care, they just need to make sure that they know the host's key as a step in the chain. This is, I believe, the key building block for DNSSEC: It gives something that secure applications can actually use, but at the same time, does not impose application semantics on the DNS system beyond a simple mapping, nor does it require the authorities to understand all the 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 Apr 23 08:43:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED37928C6AB; Thu, 23 Apr 2009 08:43:56 -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 YhqUD0DaJXuY; Thu, 23 Apr 2009 08:43:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11B5428C687; Thu, 23 Apr 2009 08:43:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx13H-000FZR-JW for namedroppers-data0@psg.com; Thu, 23 Apr 2009 15:41:27 +0000 Received: from [74.125.78.24] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx133-000FX0-Fx for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 15:41:20 +0000 Received: by ey-out-2122.google.com with SMTP id d26so144188eyd.65 for ; Thu, 23 Apr 2009 08:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=VAOOFW9RuuoCPvuo44NMS9Bna52wikT5hecbpK7IdCM=; b=PU13qOB0eo/1aoSb97JgRX7ClF+8dJJNcf3JDEhrox7TDnAY3UwCNnpxR4PVAgZp+S FxsT/Rlo7+pp0Ur2XR74ZchU/CGg0VcWoCH+M8ESZEuu4PvZvqkr7T9TnsA/bzPM/Idp Z250g+XE300/66Enhh2e3NBgQ8IDCjvDeaJpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=UL5rO4KeLITFkjtX+lzwvJxV9vjPrY6K4gKNGjBEPUE2NxxUEQ3vr6+D8CyTjd/pVd Z2iyodxcl1QttSSXhmuXDdAQe4lI1AylCN3aVoePZjx302MMtzDFunYfNNs/dlQEUqWw 8jDmF800xcGMNEaredcKA7ejlH0i5gZQbr4cY= MIME-Version: 1.0 Received: by 10.210.126.18 with SMTP id y18mr1156314ebc.45.1240501272174; Thu, 23 Apr 2009 08:41:12 -0700 (PDT) In-Reply-To: <17616.1240499031@nsa.vix.com> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> From: bert hubert Date: Thu, 23 Apr 2009 17:40:57 +0200 Message-ID: <3efd34cc0904230840l18c96a35lba7e67adfd540b6d@mail.gmail.com> Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? To: Paul Vixie Cc: Stephane Bortzmeyer , Aki Tuomi , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 5:03 PM, Paul Vixie wrote: > thanks for correctly channeling my spirit. =A0the other reasons i don't > support adoption of cookies or edns-ping are: it adds a lot of complexity > in order to solve a problem that we're not having (hop by hop corruption) We don't? I thought that this is what Kaminsky was all about.. > while failing to solve a problem we are having (end to end corruption); You appear to labour under the idea that the people who are currently corrupting some people's DNS (presumably these are the NXDOMAIN redirectors, or perhaps OpenDNS), will stop doing so if you deploy DNSSEC to authoritative resolvers and recursor. It won't work that way. >> Not a big deal, IMHO, the increased channel security is worth it, but >> it is something to keep in mind. > > it is a VERY BIG deal. =A0am i the only one here to groks the size of the > installed base? =A0changes we make to the hop-by-hop are amplified by the > number of endpoints. =A0channeling bob halley: "ok, it works in the lab, > now multiply all your numbers by six million." =A0except here it's 600 > million. You keep saying that but you don't have the numbers. You claimed DNS-0x20 was trouble free yet it turned out that very important domains (like google.com) failed for DNS-0x20 users. "To measure is to know", and I do in fact have the EDNS-PING numbers. The results are a very limited number of extra queries, and these are 100.00% aimed at those few servers which reject EDNS-PING carrying queries instead of ignoring them. This includes none of the important nameserver implementations, and appears to be limited to some load balancers. These would indeed suffer 1 extra query per hour or so do determine if their support for EDNS(-PING) has changed (upwardly). Most of these servers also reject EDNS queries anyhow. So please stick to facts instead of this hand waving which does not befit an engineer. Bert -- to unsubscribe send a message to namedroppers-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 Apr 23 08:48:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303B328C138; Thu, 23 Apr 2009 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.229, 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 tnLeAQUczml8; Thu, 23 Apr 2009 08:48:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B86F28C545; Thu, 23 Apr 2009 08:48:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx18H-000GPv-5t for namedroppers-data0@psg.com; Thu, 23 Apr 2009 15:46:37 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx181-000GN9-IU for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 15:46:28 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 20DD628C6A9; Thu, 23 Apr 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090423154502.20DD628C6A9@core3.amsl.com> Date: Thu, 23 Apr 2009 08:45:02 -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 Proxy Implementation Guidelines Author(s) : R. Bellis Filename : draft-ietf-dnsext-dnsproxy-05.txt Pages : 13 Date : 2009-04-23 This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-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-dnsproxy-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-23083006.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 Apr 23 09:11:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE9228C542; Thu, 23 Apr 2009 09:11:25 -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 LnmHhyTxwpaC; Thu, 23 Apr 2009 09:11:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C10D228C2D7; Thu, 23 Apr 2009 09:11:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx1TL-000IWR-Sk for namedroppers-data0@psg.com; Thu, 23 Apr 2009 16:08:23 +0000 Received: from [2001:748:301::2] (helo=shinjuku.zaphods.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx1T8-000IUP-60 for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 16:08:16 +0000 Received: from zaphodb by shinjuku.zaphods.net with local (Exim 4.69) (envelope-from ) id 1Lx1T7-0002N2-8b; Thu, 23 Apr 2009 18:08:09 +0200 Date: Thu, 23 Apr 2009 18:08:09 +0200 From: Stefan Schmidt To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090423160809.GD870@zaphods.net> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17616.1240499031@nsa.vix.com> X-Origin-AS: AS5430 X-NCC-nic-hdl: ZAP-RIPE User-Agent: Mutt/1.5.18 (2008-05-17) X-bounce-key: BOUNCE_ID;zaphodb@zaphods.net;1240502890;8d8ceccd; Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Hey Paul, On Thu, Apr 23, 2009 at 03:03:51PM +0000, Paul Vixie wrote: > but as to the matter of extra packets: > > > Not a big deal, IMHO, the increased channel security is worth it, but > > it is something to keep in mind. > > it is a VERY BIG deal. am i the only one here to groks the size of the > installed base? changes we make to the hop-by-hop are amplified by the > number of endpoints. channeling bob halley: "ok, it works in the lab, > now multiply all your numbers by six million." except here it's 600 > million. Well i don't know how you would implement EDNS PING but Bert's code does cache who is a EDNS PING talker and who is not, so it's more like 1 extra packet every hour or day than for every query. I (too) briefly deployed Bert's PowerDNS recursor svn trunk code and did not experience a noticable deal of extra packets altough in addition to roughly 700 authoritative EDNS PING talkers all of my own authoritatives were EDNS PING enabled so a good deal of queries were already protected back then. Of course it's not likely that we discovered all potential pitfalls, or even all implementations that do EDNS wrong like those f5 loadbalancers mentioned earlier, but IMO it's well worth the hassle. What is beyond me is why EDNS PING would be such a big deal when DNSSEC is likely to have several times the impact when we're talking compatability or packets. Stefan -- - Of course it's your fault! Everything that goes wrong around here is your fault! It says so in your contract. Quark to Rom, "Heart of Stone.", ST-DS9 -- to unsubscribe send a message to namedroppers-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 Apr 23 09:16:50 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C35E3A6B09; Thu, 23 Apr 2009 09:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.367 X-Spam-Level: X-Spam-Status: No, score=-5.367 tagged_above=-999 required=5 tests=[AWL=-0.319, 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 reJSe-aY8lkJ; Thu, 23 Apr 2009 09:16:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4165E3A69ED; Thu, 23 Apr 2009 09:16:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx1Ym-000JJN-2g for namedroppers-data0@psg.com; Thu, 23 Apr 2009 16:14:00 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx1YZ-000JHs-UZ for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 16:13:53 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3NGDfwS024488; Thu, 23 Apr 2009 09:13:41 -0700 (PDT) Cc: Nicholas Weaver , Stephane Bortzmeyer , Aki Tuomi , namedroppers@ops.ietf.org Message-Id: From: Nicholas Weaver To: Paul Vixie In-Reply-To: <17616.1240499031@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 09:13:41 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 8:03 AM, Paul Vixie wrote: > thanks for correctly channeling my spirit. the other reasons i don't > support adoption of cookies or edns-ping are: it adds a lot of > complexity > in order to solve a problem that we're not having (hop by hop > corruption) > while failing to solve a problem we are having (end to end > corruption); > and, it changes the edns protocol due to an inherent downgrade attack. EDNS0 is really not about "hop by hop" vs "end-to-end", its "out of path" vs "in path" What in-path corruption do we currently have that is NOT directly attributable to the recursive resolver itself? > but as to the matter of extra packets: > >> Not a big deal, IMHO, the increased channel security is worth it, but >> it is something to keep in mind. > > it is a VERY BIG deal. am i the only one here to groks the size of > the > installed base? changes we make to the hop-by-hop are amplified by > the > number of endpoints. channeling bob halley: "ok, it works in the lab, > now multiply all your numbers by six million." except here it's 600 > million. Except that for aggregate traffic, DNS is in the noise. So nothing * 3 is still practically nothing (assuming the duplication-based fallback for non-support of EDNS0 ping). Thus extra traffic ONLY matters for servers which are a) Refusing to apply a simple patch and b) Are already operating within a significant fraction of their theoretical maximum load. How many cases do that apply? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From nielsen@unitedvacations.com Thu Apr 23 10:31:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFBB3A6EAE; Thu, 23 Apr 2009 10:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.461 X-Spam-Level: X-Spam-Status: No, score=-25.461 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, 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 azsL3io5xXHV; Thu, 23 Apr 2009 10:31:35 -0700 (PDT) Received: from host29-63-dynamic.180-80-r.retail.telecomitalia.it (host29-63-dynamic.180-80-r.retail.telecomitalia.it [80.180.63.29]) by core3.amsl.com (Postfix) with SMTP id 3B0F03A6DBC; Thu, 23 Apr 2009 10:31:30 -0700 (PDT) From: "Frank Crow" To: <"aaa-archive@lists.ietf.org, atommib-archive@lists.ietf.org, capwap-archive@lists.ietf.org, dnsext-archive@lists.ietf.org, idn-archive@lists.ietf.org, iporpr-archive"@lists.ietf.org> Subject: Why rep watches are better Date: Thu, 23 Apr 2009 13:32:51 -0500 Message-ID: <6962rqg909203DYYWaaa-archive@lists.ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Money is tight, times are hard. Christmas is over. Time to get a new Watch! http://www.gekodatag.cn At Diam0nd Reps we specialize in fine watches imitations, offering our customers the same beauty and craftsmanship that an original carries, matched by a ridiculously low price that is sometimes hard to believe, but very much true! http://www.gekodatag.cn With so many watches that look and work like the real thing, I guarantee you'll have a delicious time finding yours at our store! From owner-namedroppers@ops.ietf.org Thu Apr 23 10:55:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B1A3A6C88; Thu, 23 Apr 2009 10:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 vPshT54Gt304; Thu, 23 Apr 2009 10:55:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C9883A680F; Thu, 23 Apr 2009 10:55:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx33c-0003yT-5h for namedroppers-data0@psg.com; Thu, 23 Apr 2009 17:49:56 +0000 Received: from [94.198.152.69] (helo=arn1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx33O-0003xY-CF for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 17:49:49 +0000 Received: from sidn.nl ([192.168.2.12]) by arn1-kamx.sidn.nl with ESMTP id n3NHndl1014181 for ; Thu, 23 Apr 2009 19:49:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 19:50:03 +0200 Message-ID: <850A39016FA57A4887C0AA3C8085F949C4F2CD@KAEVS1.SIDN.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Thread-Index: AcnELFgt1dxw/FoAREu8lNizafC9kwACspTw References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> <3efd34cc0904230840l18c96a35lba7e67adfd540b6d@mail.gmail.com> From: "Antoin Verschuren" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkkgbXVz dCBzb3J0IG9mIGV4cHJlc3MgbXkgc3VwcG9ydCB0byBWaXhpZSdzIHdvcnJpZXMgaGVyZSwgYW5k IHNheSAibWUgdG9vIg0KDQpJIHRoaW5rIEVORFMwIFBJTkcgYW5kIGluIGZhY3QgYW55IGhvcC1i eS1ob3Agc2VjdXJpdHkgc29sdXRpb24sIGluY2x1ZGluZyAweDIwIGJ0dywgdGhhdCB3ZSBpbnZl bnQgaW4gdGhpcyBLYW1pbnNraSBlcmEgd2lsbCBiZWNvbWUgYSB0cnVlIHNlY3VyaXR5IGJ1cmRl biBsYXRlciBvbiB3aGVuIHdlIG1pZ2h0IGhhdmUgZGVwbG95ZWQgRE5TU0VDIG9yIGFub3RoZXIg ZW5kLXRvLWVuZCBzZWN1cml0eSBleHRlbnNpb24uIEROUyBtaWdodCBlbmQgdXAgYmVjb21pbmcg c28gY29tcGxleCB0aGF0IG9ubHkgYSBmZXcgb24gdGhpcyBlYXJ0aCB3aWxsIHN0aWxsIHVuZGVy c3RhbmQgaXQsIGFuZCBldmVyeW9uZSBlbHNlIGlzIGp1c3QgdHJ5aW5nIHRvIHVuZGVyc3RhbmQg aXQgaG9waW5nIHRoZXkgZG8gdGhlIHJpZ2h0IHRoaW5nLiBNYWtpbmcgdGhlIHByb3RvY29sIHNv IGZ1bGwgb2YgbWlub3IgaW1wcm92ZW1lbnRzIGlzIG5vdCBhIGdvb2QgYW5kIHJvYnVzdCBkZXNp Z24sIGFuZCB3aWxsIHJlc3VsdCBpbiBvcGVyYXRvcnMgbWFraW5nIG1vcmUgZXJyb3JzLg0KDQpT byBteSBmaXJzdCBxdWVzdGlvbiB3b3VsZCBiZSwgaXMgaXQgdGhlIGludGVudGlvbiB0byB0dXJu IEVETlMwIHBpbmcgT0ZGIG9uY2Ugd2UgaGF2ZSBkZXBsb3llZCBETlNTRUMgc28gd2UgY2FuIHJl ZHVjZSB0aGUgY29tcGxleGl0eSBhbmQgdHJhZmZpYyBhZ2FpbiA/DQoNCkFuZCBzcGVha2luZyBv ZiB0cmFmZmljLCB5ZXMgdGhhdCdzIG15IGdyZWF0ZXN0IHdvcnJ5IHRvby4gSSB0aGluayBldmVy eSBiaXQgY291bnRzLiBXZSBzaG91bGQgZGVzaWduIGFuIGVmZmljaWVudCBwcm90b2NvbCwgYW5k IG5vdCBhbiBTUzcgbW9uc3Rlci4gRXZlcnkgZXh0cmEgcXVlcnkgb24gdGhlIHdpcmUgdGhhdCBj YW4gYmUgYXZvaWRlZCBpcyBhIHF1ZXJ5IHRvbyBtdWNoLiBTcGVha2luZyBvZiB0aGUgb3BlcmF0 aW9uYWwgZXhwZXJpZW5jZSwgSSBjYW4gc2F5IHRoYXQgZXhjZXNzaXZlIHF1ZXJ5aW5nIGlzIGEg Z3JlYXRlciB0aHJlYXQgdG8gdGhlIEROUyBhdCB0aGlzIG1vbWVudCB0aGFuIGFueSBLYW1pbnNr aSBzdHlsZSBhdHRhY2suIEkgaGF2ZSB0byBkZWFsIHdpdGggdHJhZmZpYyBpbmNpZGVudHMgb24g b3VyIG5hbWVzZXJ2ZXJzIG11bHRpcGxlIHRpbWVzIGEgbW9udGgsIGFuZCBJJ3ZlIG5vdCBzZWVu IGEgS2FtaW5za2kgYXR0YWNrIGxpdmUgeWV0Lg0KDQpJZiB0aGUgRE5TIGluZnJhc3RydWN0dXJl IGNvbGxhcHNlcyBiZWNhdXNlIG9mIHRoZSBleHRyYSB0cmFmZmljIGNhdXNlZCBieSBkaXNhYmxp bmcgb3IgYnlwYXNzaW5nIGNhY2hpbmcgb3IgcmUtcXVlcnlpbmcgdGhlcmUgd29uJ3QgYmUgYW55 IG1vcmUgcmVzcG9uc2VzIHRvIHF1ZXJpZXMuIFNlY3VyZSBvciBpbnNlY3VyZSByZXNwb25zZXMu DQoNCkFudG9pbiBWZXJzY2h1cmVuDQoNClRlY2huaWNhbCBQb2xpY3kgQWR2aXNvcg0KU0lETg0K VXRyZWNodHNld2VnIDMxMA0KUE8gQm94IDUwMjINCjY4MDIgRUEgQXJuaGVtDQpUaGUgTmV0aGVy bGFuZHMNCg0KVCArMzEgMjYgMzUyNTUwMA0KRiArMzEgMjYgMzUyNTUwNQ0KTSArMzEgNiAyMzM2 ODk3MA0KRSBhbnRvaW4udmVyc2NodXJlbkBzaWRuLm5sDQpXIGh0dHA6Ly93d3cuc2lkbi5ubC8N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1uYW1lZHJvcHBl cnNAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItDQo+IG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBiZXJ0IGh1YmVydA0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjMs IDIwMDkgNTo0MSBQTQ0KPiBUbzogUGF1bCBWaXhpZQ0KPiBDYzogU3RlcGhhbmUgQm9ydHptZXll cjsgQWtpIFR1b21pOyBuYW1lZHJvcHBlcnNAb3BzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb ZG5zZXh0XSBSZTogQWRvcHQgRUROUzAgUGluZywgYmVuZWZpdHMgdnMgZGlzYWR2YW50YWdlcyA/ DQo+IA0KPiBPbiBUaHUsIEFwciAyMywgMjAwOSBhdCA1OjAzIFBNLCBQYXVsIFZpeGllIDx2aXhp ZUBpc2Mub3JnPiB3cm90ZToNCj4gPiB0aGFua3MgZm9yIGNvcnJlY3RseSBjaGFubmVsaW5nIG15 IHNwaXJpdC4gIHRoZSBvdGhlciByZWFzb25zIGkgZG9uJ3QNCj4gPiBzdXBwb3J0IGFkb3B0aW9u IG9mIGNvb2tpZXMgb3IgZWRucy1waW5nIGFyZTogaXQgYWRkcyBhIGxvdCBvZg0KPiBjb21wbGV4 aXR5DQo+ID4gaW4gb3JkZXIgdG8gc29sdmUgYSBwcm9ibGVtIHRoYXQgd2UncmUgbm90IGhhdmlu ZyAoaG9wIGJ5IGhvcA0KPiBjb3JydXB0aW9uKQ0KPiANCj4gV2UgZG9uJ3Q/IEkgdGhvdWdodCB0 aGF0IHRoaXMgaXMgd2hhdCBLYW1pbnNreSB3YXMgYWxsIGFib3V0Li4NCj4gDQo+ID4gd2hpbGUg ZmFpbGluZyB0byBzb2x2ZSBhIHByb2JsZW0gd2UgYXJlIGhhdmluZyAoZW5kIHRvIGVuZCBjb3Jy dXB0aW9uKTsNCj4gDQo+IFlvdSBhcHBlYXIgdG8gbGFib3VyIHVuZGVyIHRoZSBpZGVhIHRoYXQg dGhlIHBlb3BsZSB3aG8gYXJlIGN1cnJlbnRseQ0KPiBjb3JydXB0aW5nIHNvbWUgcGVvcGxlJ3Mg RE5TIChwcmVzdW1hYmx5IHRoZXNlIGFyZSB0aGUgTlhET01BSU4NCj4gcmVkaXJlY3RvcnMsIG9y IHBlcmhhcHMgT3BlbkROUyksIHdpbGwgc3RvcCBkb2luZyBzbyBpZiB5b3UgZGVwbG95DQo+IERO U1NFQyB0byBhdXRob3JpdGF0aXZlIHJlc29sdmVycyBhbmQgcmVjdXJzb3IuIEl0IHdvbid0IHdv cmsgdGhhdA0KPiB3YXkuDQo+IA0KPiA+PiBOb3QgYSBiaWcgZGVhbCwgSU1ITywgdGhlIGluY3Jl YXNlZCBjaGFubmVsIHNlY3VyaXR5IGlzIHdvcnRoIGl0LCBidXQNCj4gPj4gaXQgaXMgc29tZXRo aW5nIHRvIGtlZXAgaW4gbWluZC4NCj4gPg0KPiA+IGl0IGlzIGEgVkVSWSBCSUcgZGVhbC4gIGFt IGkgdGhlIG9ubHkgb25lIGhlcmUgdG8gZ3Jva3MgdGhlIHNpemUgb2YgdGhlDQo+ID4gaW5zdGFs bGVkIGJhc2U/ICBjaGFuZ2VzIHdlIG1ha2UgdG8gdGhlIGhvcC1ieS1ob3AgYXJlIGFtcGxpZmll ZCBieSB0aGUNCj4gPiBudW1iZXIgb2YgZW5kcG9pbnRzLiAgY2hhbm5lbGluZyBib2IgaGFsbGV5 OiAib2ssIGl0IHdvcmtzIGluIHRoZSBsYWIsDQo+ID4gbm93IG11bHRpcGx5IGFsbCB5b3VyIG51 bWJlcnMgYnkgc2l4IG1pbGxpb24uIiAgZXhjZXB0IGhlcmUgaXQncyA2MDANCj4gPiBtaWxsaW9u Lg0KPiANCj4gWW91IGtlZXAgc2F5aW5nIHRoYXQgYnV0IHlvdSBkb24ndCBoYXZlIHRoZSBudW1i ZXJzLiBZb3UgY2xhaW1lZA0KPiBETlMtMHgyMCB3YXMgdHJvdWJsZSBmcmVlIHlldCBpdCB0dXJu ZWQgb3V0IHRoYXQgdmVyeSBpbXBvcnRhbnQNCj4gZG9tYWlucyAobGlrZSBnb29nbGUuY29tKSBm YWlsZWQgZm9yIEROUy0weDIwIHVzZXJzLg0KPiANCj4gIlRvIG1lYXN1cmUgaXMgdG8ga25vdyIs IGFuZCBJIGRvIGluIGZhY3QgaGF2ZSB0aGUgRUROUy1QSU5HIG51bWJlcnMuDQo+IFRoZSByZXN1 bHRzIGFyZSBhIHZlcnkgbGltaXRlZCBudW1iZXIgb2YgZXh0cmEgcXVlcmllcywgYW5kIHRoZXNl IGFyZQ0KPiAxMDAuMDAlIGFpbWVkIGF0IHRob3NlIGZldyBzZXJ2ZXJzIHdoaWNoIHJlamVjdCBF RE5TLVBJTkcgY2FycnlpbmcNCj4gcXVlcmllcyBpbnN0ZWFkIG9mIGlnbm9yaW5nIHRoZW0uIFRo aXMgaW5jbHVkZXMgbm9uZSBvZiB0aGUgaW1wb3J0YW50DQo+IG5hbWVzZXJ2ZXIgaW1wbGVtZW50 YXRpb25zLCBhbmQgYXBwZWFycyB0byBiZSBsaW1pdGVkIHRvIHNvbWUgbG9hZA0KPiBiYWxhbmNl cnMuDQo+IA0KPiBUaGVzZSB3b3VsZCBpbmRlZWQgc3VmZmVyIDEgZXh0cmEgcXVlcnkgcGVyIGhv dXIgb3Igc28gZG8gZGV0ZXJtaW5lIGlmDQo+IHRoZWlyIHN1cHBvcnQgZm9yIEVETlMoLVBJTkcp IGhhcyBjaGFuZ2VkICh1cHdhcmRseSkuDQo+IE1vc3Qgb2YgdGhlc2Ugc2VydmVycyBhbHNvIHJl amVjdCBFRE5TIHF1ZXJpZXMgYW55aG93Lg0KPiANCj4gU28gcGxlYXNlIHN0aWNrIHRvIGZhY3Rz IGluc3RlYWQgb2YgdGhpcyBoYW5kIHdhdmluZyB3aGljaCBkb2VzIG5vdA0KPiBiZWZpdCBhbiBl bmdpbmVlci4NCj4gDQo+ICAgICAgQmVydA0KPiANCj4gLS0NCj4gdG8gdW5zdWJzY3JpYmUgc2Vu ZCBhIG1lc3NhZ2UgdG8gbmFtZWRyb3BwZXJzLXJlcXVlc3RAb3BzLmlldGYub3JnIHdpdGgNCj4g dGhlIHdvcmQgJ3Vuc3Vic2NyaWJlJyBpbiBhIHNpbmdsZSBsaW5lIGFzIHRoZSBtZXNzYWdlIHRl eHQgYm9keS4NCj4gYXJjaGl2ZTogPGh0dHA6Ly9vcHMuaWV0Zi5vcmcvbGlzdHMvbmFtZWRyb3Bw ZXJzLz4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiA5LjYuMyAoQnVp bGQgMzAxNykNCg0Kd3NCVkF3VUJTZkNxU3pxSHJNODgzQWduQVFoNTRBZ0F0NnBlcmNNZjJLRFNV dU1QSzlxMjlyL0RCOHVsK0s0Tw0KdjBUNEZYcVhVQlVOK0prSmNuRUNKQmZ3c0ZsL0FDWUJpeDFU RnZ2QlhjbXlxVWNuSFc1RmxVU0hFSzF5MXJVLw0KNnRlcVh5cWZ3bmZUZXRTbTc3L3E3eDZRU2dT TTY5TVIwSS9MMUtxZDVhblNTb0dHZGJselBsUWhoaWlLUWcvdg0KWkZadmlJSXVZVk9kVFkrblcw U0JtZXhianAwbi9idEQvUnlDUUZPQlhFWU5OeE9CeGF2RFRJMGY1VEsvZ1BwcA0KaERmT3ZNZzdn RlRjeWZtem05ZW1qSVphbmk0bHArMHVpSlBLODRTWkUvaktMeVlrQWhXcXcraFJjLzl4RXFvRg0K VUp6MW1CMHZoekNNalBVemY4Nm00Z21vbk1rMTgxNEMzY2NEdlV1b2xXY0VlellmcUNLb1FBPT0N Cj1vZnJ3DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0K -- to unsubscribe send a message to namedroppers-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 Apr 23 11:25:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D6F3A6E9A; Thu, 23 Apr 2009 11:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 By9VOieOzuua; Thu, 23 Apr 2009 11:25:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F0F83A6886; Thu, 23 Apr 2009 11:25:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx3X7-0007Q2-Sp for namedroppers-data0@psg.com; Thu, 23 Apr 2009 18:20:25 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx3Ws-0007NN-Ht for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 18:20:16 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id F09A1A1022 for ; Thu, 23 Apr 2009 18:20:04 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] we need an IAB statement on Secure DNS X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Thu, 23 Apr 2009 18:20:04 +0000 Message-ID: <26249.1240510804@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Chairs, please invoke some kind of review process by the IAB so that we can get some direction on Secure DNS. We've got TSIG and TKEY and GSS TSIG and SIG(0), and we've got DNSSEC, and we've got SPR. To me that's enough, it's a complete system supporting both end to end (DNSSEC) and hop by hop (SPR, TSIG, or or TKEY+SIG(0)) security. However, the engineering mindset that dominates this working group is now way into its customary overshoot (DNS-0x20, EDNS PING, cookies) and there is at least one major non-working-group project (dnscurve) in the works. The effect of this overshoot is to dilute interest in existing Secure DNS technologies. Fence sitters can say "well clearly the wheels are still turning, let's see how it shakes out before we make any investment." This fulfills the prophecy of these overshooters ("DNSSEC is too hard to deploy, so clearly we need to continue investigating other solutions.") What the Secure DNS effort needs is some nontechnical governance. I'd like the IAB to weigh in on the question: "Is Secure DNS complete?" so that the working group can know a priori and on nontechnical grounds whether to continue accepting new work items in this area. (Note that I have personally quashed three mindblowingly better solutions to things that DNSSEC got wrong, because at some point you have to cut and print.) (Also note that I've been working on Secure DNS for close to 15 years now, and the apparent endlessness of it is starting to get on my nerves, and is NOT a simple artifact of protocol quality, which is why I'm indicting the engineering mindset prevalant in the DNSEXT working group.) Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 23 12:10:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCFE3A72AB; Thu, 23 Apr 2009 12:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.378, 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 W22JGX-77DAK; Thu, 23 Apr 2009 12:10:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 119613A72E1; Thu, 23 Apr 2009 12:10:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx4Gm-000C5q-QD for namedroppers-data0@psg.com; Thu, 23 Apr 2009 19:07:36 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx4GX-000C2g-EE for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 19:07:27 +0000 Received: from [10.31.200.142] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3NJ7DiQ026172; Thu, 23 Apr 2009 15:07:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <26249.1240510804@nsa.vix.com> References: <26249.1240510804@nsa.vix.com> Date: Thu, 23 Apr 2009 15:07:10 -0400 To: Paul Vixie From: Edward Lewis Subject: Re: [dnsext] we need an IAB statement on Secure DNS Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 18:20 +0000 4/23/09, Paul Vixie wrote: >Chairs, please invoke some kind of review process by the IAB Yes, Chairs, please do. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-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 Apr 23 12:51:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCC93A6B77; Thu, 23 Apr 2009 12:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.358 X-Spam-Level: X-Spam-Status: No, score=-5.358 tagged_above=-999 required=5 tests=[AWL=-0.310, 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 kQvz4PDLhYFD; Thu, 23 Apr 2009 12:51:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8BB173A6BA5; Thu, 23 Apr 2009 12:51:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx4u3-000GdB-O4 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 19:48:11 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx4tp-000Gbt-AT for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 19:48:04 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3NJln23022862; Thu, 23 Apr 2009 12:47:49 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> From: Nicholas Weaver To: Paul Vixie In-Reply-To: <26249.1240510804@nsa.vix.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] we need an IAB statement on Secure DNS Date: Thu, 23 Apr 2009 12:47:48 -0700 References: <26249.1240510804@nsa.vix.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 11:20 AM, Paul Vixie wrote: > Chairs, please invoke some kind of review process by the IAB so that > we can > get some direction on Secure DNS. We've got TSIG and TKEY and GSS > TSIG and > SIG(0), and we've got DNSSEC, and we've got SPR. To me that's > enough, it's > a complete system supporting both end to end (DNSSEC) and hop by hop > (SPR, > TSIG, or or TKEY+SIG(0)) security. However, the engineering mindset > that > dominates this working group is now way into its customary overshoot > (DNS-0x20, EDNS PING, cookies) and there is at least one major > non-working-group project (dnscurve) in the works. Actually, I'd argue differently, as someone who wants a secure Internet, not "Secure DNS": Hop by hop cryptographic protection is unnecessary and unuseful for general purposes (as opposed to distributing zone files or similar within a group of systems, which is what TSIG is for, but an SSH tunnel works just as well...). Hop by hop protections only need to protect against out-of-path attackers, as the one key in-path attacker is the recursive resolver itself, which hop to hop protections do not defend against. Yet hop-by-hop cryptographic systems have all the problems otherwise associated with cryptographic systems, including key management, changes to authority management, etc etc etc. Thus I believe "Secure" DNS should consider... A) Hop-by-hop protection against out-of-path attackers ONLY. Such protection should be deployable with changes to only the code base of the authorities and/or resolvers, NOT the management of the systems. This is why 0x20 and EDNS0 Ping are so attractive, and why I believe that TKEY+SIG(0), dnscurve, etc, are just fine thrown in the trash can for general use. In fact, general cryptographic protections for hop-by-hop data for DNS are WORSE than useless: they provide an illusion of "security", without providing a significant increase in system security in most cases. [1] B) End-to-end cryptographic protection, validated by the END HOST (not the recursive resolver), targeted at authenticating Name->data mappings for application use (mostly for keys), not Name->Address mappings [2]. A is 0x20 and EDNS0-ping. B is DNSSEC with a better API and some usage conventions. > (Note that I have personally quashed three mindblowingly better > solutions > to things that DNSSEC got wrong, because at some point you have to > cut and > print.) (Also note that I've been working on Secure DNS for close > to 15 > years now, and the apparent endlessness of it is starting to get on my > nerves, and is NOT a simple artifact of protocol quality, which is > why I'm > indicting the engineering mindset prevalant in the DNSEXT working > group.) And at the same time, I'm not willing to sacrifice achievable and deployable protection against out-of-path adversaries today for the hope of protection against in-path adversaries tomorrow. 0x20 and EDNS0-ping should not be obstacles for DNSSEC deployment, and if they are viewed as obstacles by some, this is reflecting poorly on DNSSEC's value proposition. DNSSEC has had years to try to win adoption in the market. So I'd personally state: End to end integrity for name->data mappings is the goal. DNSSEC, if deployed, provides this. Since we are obviously lacking DEPLOYED end-to-end integrity mechanisms for DNS, it is important that we ensure hop-by-hop protection against out-of-path adversaries with protection of 1 in 2^40 (minimum), 1 in 2^64 (ideal), with changes that are code-only: no changes to authority or resolver management but only the code running on those servers. So yes, by all means do a review process. But such a review should include use cases and deployability concerns. It should not be "If this all was deployed.." but also "Why isn't the existing stuff deployed?" and "Should we do something less if it can be deployed today?" [1] In the same boat goes DNSSEC validation on the recursive resolver. Validating DNSSEC at the recursive resolver offers effectively NO security benefits, and IMO, that model should be discarded. If I'm able to do in-path attacks on the DNS packets between the authority and the recursive resolver, I'm probably able to do the same attack on the user's TCP connections (see http://lists.immunitysec.com/pipermail/dailydave/2009-March/005601.html ) [2] I can always get "as secure as my network is for the data itself" name->address mappings by simply generating my own iterative request. And the externality of such behavior doesn't affect me, just the authorities. -- to unsubscribe send a message to namedroppers-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 Apr 23 13:31:04 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726D628C6F6; Thu, 23 Apr 2009 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, 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 YT-uHfBwq4Os; Thu, 23 Apr 2009 13:31:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8E6A28C6FF; Thu, 23 Apr 2009 13:30:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5W9-000KN9-R1 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 20:27:33 +0000 Received: from [74.125.46.28] (helo=yw-out-2324.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5Vx-000KMQ-K3 for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 20:27:27 +0000 Received: by yw-out-2324.google.com with SMTP id 3so481426ywj.71 for ; Thu, 23 Apr 2009 13:27:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.56.17 with SMTP id e17mr1621707aga.61.1240518440660; Thu, 23 Apr 2009 13:27:20 -0700 (PDT) In-Reply-To: <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> Date: Thu, 23 Apr 2009 13:27:19 -0700 Message-ID: Subject: Re: [dnsext] we need an IAB statement on Secure DNS From: Matthew Dempsky To: Nicholas Weaver Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 12:47 PM, Nicholas Weaver wrote: > A) =A0Hop-by-hop protection against out-of-path attackers ONLY. For my benefit at least, would you mind clarifying exactly what you mean by "out-of-path attackers"? In particular, are routers that just forward IP packets along the path from the source to the destination considered "out-of-path" or not? E.g., if I run "traceroute ns1.google.com" from my computer right now, I see there are 14 routers between my computer and ns1.google.com. If I then run "dig www.google.com @ns1.google.com" and one of these 14 routers were to act maliciously, would they be considered "out-of-path" or not? (I ask only because I've found the use of "hop-by-hop" on this mailing list to mean "from-DNS-application-to-next-DNS-application" rather than "from-IP-host-to-next-IP-host" confusing at times, and it might alter the interpretation of "out-of-path".) -- to unsubscribe send a message to namedroppers-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 Apr 23 13:37:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04C83A72ED; Thu, 23 Apr 2009 13:37:10 -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=-1.864, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_HTML_URI_LHOST31=1.666] 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 PphfCLws-Sfj; Thu, 23 Apr 2009 13:37:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7566128C712; Thu, 23 Apr 2009 13:36:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5dR-000L1n-Rh for namedroppers-data0@psg.com; Thu, 23 Apr 2009 20:35:05 +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 1Lx5d7-000L0A-Rz for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 20:34:58 +0000 Message-ID: <49F0D0E1.8040504@ca.afilias.info> Date: Thu, 23 Apr 2009 22:34:41 +0200 From: Shane Kerr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Aki Tuomi CC: namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B52@fi-hel2ex01.nordiclan.net> In-Reply-To: <86048CA3B4B17E459FFD4F3F383AD88F13F27B52@fi-hel2ex01.nordiclan.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Aki, Aki Tuomi wrote: >>>> There is another cost for the authoritative server which did not >>>> upgrade to edns-ping: an increase in the number of queries by >>>> edns-ping resolvers trying to find out if there was a downgrade >> attack >>>> or if the authoritative server really does not support edns-ping. >> Not >>>> a big problem, IMHO, but it should be mentioned for completeness. >>>> >>>> >>> I think any solution suffers from this drawback, not just EDNS0 PING. >> Not necessarily. >> >> One idea is registering what features a name server supports in the >> DNS(*). >> >> So, one could: >> >> * create a new RTYPE to encode which EDNS0 options were supported >> * create a new EDNS0 option which the parent server would use to >> report EDNS0 support from child records (as documented in the RTYPE) >> >> So, as the operator of TIME-TRAVELLERS.ORG, my zone might have: >> >> time-travellers.org. NS ns1.time-travellers.org. >> NS ns2.time-travellers.org. >> ns1.time-travellers.org A 1.2.3.4 >> EDNS0OPT ( NSID PING ) >> ns2.time-travellers.org A 2.3.4.5 >> EDNS0OPT ( NSID PING ) >> >> The EDNS0OPT would be a new type of glue. >> >> -- >> Shane >> >> (*) This idea occurs to me after looking at DNSCurve. DNScurve encodes >> a >> public key in the NS set for a zone. So your NS set may be: >> >> example.com NS d4fdfsu8j3j331234faes32aaasdfGG.example.com >> NS lkj4444lkjsadfo89unasdfnasdlqu1.example.com >> >> A clever idea, and one that can be extended here. > > Yes, which requires extra requests. You still have to (periodically) query the other party. Probably quite often. So there is still no free lunch. The idea is that this information would get passed along in the replies to queries via a new EDNS0 option; no extra queries would be required to get this information. Now that might not be a practical idea, but in theory it can work. :) I don't think there are extra requests. Certainly not for the DNSCurve, and I think not for registering EDNS0 Ping support within the DNS (although again, it's all quite vague without solid descriptions at this point... I guess I'll have to hammer out a draft). -- 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 Thu Apr 23 13:42:57 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EECF03A6B81; Thu, 23 Apr 2009 13:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-0.937, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 10NM3ELo4xEW; Thu, 23 Apr 2009 13:42:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01ED93A6B2D; Thu, 23 Apr 2009 13:42:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5jE-000Lgf-O4 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 20:41:04 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5j1-000LfS-Ox for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 20:40:57 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 88B482FE960A for ; Thu, 23 Apr 2009 20:40:50 +0000 (UTC) Date: Thu, 23 Apr 2009 16:40:48 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090423204048.GJ68912@shinkuro.com> References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: No hat. On Thu, Apr 23, 2009 at 12:47:48PM -0700, Nicholas Weaver wrote: > And at the same time, I'm not willing to sacrifice achievable and > deployable protection against out-of-path adversaries today for the hope > of protection against in-path adversaries tomorrow. It seems to me that the proposed technologies are not "achievable and deployable" "today", because the techniques aren't yet standardized and we don't have actually shipping, tested-interoperable code implementing all of it. I think it is important for the purposes of this discussion to remember that we have a very hard time getting adequate review in this WG, and that difficulty will surely apply to these drafts and techniques as to others. Moreover, we have to realise that even if we like them, getting these techniques through the RFC process may run into roadblocks when we get to the IETF last call. There will be security people who ask why we are recommending a half-measure when the full measure is already standardized and into the deployment phase. That's not a silly question to ask, in my opinion. > 0x20 and EDNS0-ping should not be obstacles for DNSSEC deployment, and > if they are viewed as obstacles by some, this is reflecting poorly on > DNSSEC's value proposition. DNSSEC has had years to try to win adoption > in the market. I believe that, whether we like it or not, the relevant community is not those in the IETF, but those who regard the DNS as a massive headache, impossible to understand, that occasionally changes in mysterious and frustrating ways. If that community hears, "The DNS protocol people are still working on it to improve its security," the message is likely to be interpreted as, "Do not deploy DNSSEC just now, because the DNS weenies are still figuring out what to do about it." This is all just my personal opinion. > Since we are obviously lacking DEPLOYED end-to-end integrity mechanisms > for DNS, it is important that we ensure hop-by-hop protection against > out-of-path adversaries with protection of 1 in 2^40 (minimum), 1 in 2^64 > (ideal), with changes that are code-only: no changes to authority or > resolver management but only the code running on those servers. I have doubts that large DNS operators, when confronted with as-yet-unknown changes to their traffic patterns due to these alternative techniques, will really regard this as a code-only change. In places I have worked with operations on any scale, extensions to any protocol automatically entailed changes to operations. At the very least, I'd bet a number of monitors in some sites would have to be adjusted. I am therefore quite sceptical of claims that the proposed techniques are a code-only change. We hear one large operator expressing doubts also; it would be valuable to me to have informed input from other operators as to whether they regard the proposed techniques (to the extent they are completely defined) as a code-only change, or whether they think the techniques might impose operations changes too. Again, just my personal opinion. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 23 13:47:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72233A732B; Thu, 23 Apr 2009 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=-0.887, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=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 4-hROhnp6Dzo; Thu, 23 Apr 2009 13:47:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA5A83A7336; Thu, 23 Apr 2009 13:47:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5ns-000M4r-Tj for namedroppers-data0@psg.com; Thu, 23 Apr 2009 20:45:52 +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 1Lx5ng-000M42-40 for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 20:45:46 +0000 Message-ID: <49F0D370.2060007@ca.afilias.info> Date: Thu, 23 Apr 2009 22:45:36 +0200 From: Shane Kerr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Florian Weimer CC: namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> <82hc0fa4ed.fsf@mid.bfk.de> In-Reply-To: <82hc0fa4ed.fsf@mid.bfk.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Florian, Florian Weimer wrote: > * Shane Kerr: > >> So, one could: >> >> * create a new RTYPE to encode which EDNS0 options were supported >> * create a new EDNS0 option which the parent server would use to >> report EDNS0 support from child records (as documented in the RTYPE) >> >> So, as the operator of TIME-TRAVELLERS.ORG, my zone might have: >> >> time-travellers.org. NS ns1.time-travellers.org. >> NS ns2.time-travellers.org. >> ns1.time-travellers.org A 1.2.3.4 >> EDNS0OPT ( NSID PING ) >> ns2.time-travellers.org A 2.3.4.5 >> EDNS0OPT ( NSID PING ) >> >> The EDNS0OPT would be a new type of glue. > > I think it's not really that much more work to put a DS record there > instead of an EDNS0OPT record, so I don't think this approach offers a > got trade-off. Well, except that one needs to actually sign the parent zone for there to be any point in putting a DS record in it, which *is* a lot more work. > If you want signalling, you have to put it into the name, > Dnscurve-style. I'm not sure what you mean by "signaling". One could publish servers' level of DNS support in the name, of course. It may be more elegant in some sense to do it that way - it requires no software changes on authoritative servers, and nothing new for registries/registrars to do. But you don't *have* to do it that way. -- 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 Thu Apr 23 13:50:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB2B3A728C; Thu, 23 Apr 2009 13:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.35 X-Spam-Level: X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=-0.302, 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 56ZuDAxbOQGt; Thu, 23 Apr 2009 13:50:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9959D3A6A25; Thu, 23 Apr 2009 13:50:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5qO-000MMJ-DB for namedroppers-data0@psg.com; Thu, 23 Apr 2009 20:48:28 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5qA-000MIN-AY for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 20:48:21 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3NKmBmI000626; Thu, 23 Apr 2009 13:48:11 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <88CBC7F8-51A2-4A2C-8F21-B1F0094E1608@ICSI.Berkeley.EDU> From: Nicholas Weaver To: Matthew Dempsky In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] we need an IAB statement on Secure DNS Date: Thu, 23 Apr 2009 13:48:11 -0700 References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 1:27 PM, Matthew Dempsky wrote: > On Thu, Apr 23, 2009 at 12:47 PM, Nicholas Weaver > wrote: >> A) Hop-by-hop protection against out-of-path attackers ONLY. > > For my benefit at least, would you mind clarifying exactly what you > mean by "out-of-path attackers"? In particular, are routers that just > forward IP packets along the path from the source to the destination > considered "out-of-path" or not? An out of path attacker is not able to directly observe the DNS request or reply, but may know that such a request exists because the attacker caused the request to be generated. An in-path adversary is directly able to observe the packets. > E.g., if I run "traceroute ns1.google.com" from my computer right now, > I see there are 14 routers between my computer and ns1.google.com. If > I then run "dig www.google.com @ns1.google.com" and one of these 14 > routers were to act maliciously, would they be considered > "out-of-path" or not? That would be an in-path adversary. > (I ask only because I've found the use of "hop-by-hop" on this mailing > list to mean "from-DNS-application-to-next-DNS-application" rather > than "from-IP-host-to-next-IP-host" confusing at times, and it might > alter the interpretation of "out-of-path".) The reason why I care about the distinction: In-path adversaries are the killer, and the attacker's goal is to become an in-path adversary on the final application: But if the final application is not end-to-end seceure, who cares if the name->address mapping is correct when the already in-path adversary can directly attack the final application? And if the final application IS end-to-end secure, it never really trusted the name->address mapping, because it never trusted the name- >address mapping anymore than it trusted the network (namely, not at all). But with the HUGE exception of the recursive resolver itself being an adversary, an in-path adversary for the DNS packets is also likely to be an in-path adversary for the data packets. EG, on your example, if I traceroute to ns1.google.com and www.google.com , the traceroutes only deviate within the final network owned by Google, in the 12th hop. Up until that point, the packets follow exactly the same path. This is why I believe it is sufficient for hop by hop defenses to only focus on out-of-path adversaries, because focusing on in-path adversaries misses the real problem: the applications themselves are insecure against in-path adversaries yet all hop by hop protections can't protect against the recursive resolver itself, which has proven itself to be an adversarial party. And if the DNS community goes through all the hastles involved with cryptographic keying, the resulting system should be able to resist ALL in-path adversaries, not "All in path adversaries except the one that counts: the recursive resolver". DNSSEC can. Any hop-by-hop mechanism can not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 23 13:53:59 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EB33A6928; Thu, 23 Apr 2009 13:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.521 X-Spam-Level: X-Spam-Status: No, score=-4.521 tagged_above=-999 required=5 tests=[AWL=0.527, 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 0BevMxsS1Yxk; Thu, 23 Apr 2009 13:53:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 458723A684B; Thu, 23 Apr 2009 13:53:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5tE-000Mca-0n for namedroppers-data0@psg.com; Thu, 23 Apr 2009 20:51:24 +0000 Received: from [194.100.2.124] (helo=smtp1.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5t0-000MbB-SW for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 20:51:17 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp1.tdc.fi (Postfix) with ESMTP id BF64C581D1E for ; Thu, 23 Apr 2009 23:51:08 +0300 (EEST) Content-class: urn:content-classes:message Subject: RE: [dnsext] we need an IAB statement on Secure DNS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Apr 2009 23:27:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] we need an IAB statement on Secure DNS Thread-Index: AcnEQ6b9kNfwe/maQVW0bbhMp6zmNwADTRUg References: <26249.1240510804@nsa.vix.com> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >-----Original Message----- >From: owner-namedroppers@ops.ietf.org [mailto:owner->namedroppers@ops.ietf.org] On Behalf Of Paul Vixie >Sent: Thursday, April 23, 2009 9:20 PM >To: namedroppers@ops.ietf.org >Subject: [dnsext] we need an IAB statement on Secure DNS > >Chairs, please invoke some kind of review process by the IAB so that we can >get some direction on Secure DNS. We've got TSIG and TKEY and GSS TSIG and >SIG(0), and we've got DNSSEC, and we've got SPR. To me that's enough, it's >a complete system supporting both end to end (DNSSEC) and hop by hop (SPR, >TSIG, or or TKEY+SIG(0)) security. However, the engineering mindset that >dominates this working group is now way into its customary overshoot >(DNS-0x20, EDNS PING, cookies) and there is at least one major >non-working-group project (dnscurve) in the works. > >The effect of this overshoot is to dilute interest in existing Secure DNS >technologies. Fence sitters can say "well clearly the wheels are still >turning, let's see how it shakes out before we make any investment." This >fulfills the prophecy of these overshooters ("DNSSEC is too hard to deploy, >so clearly we need to continue investigating other solutions.") What the >Secure DNS effort needs is some nontechnical governance. I'd like the IAB >to weigh in on the question: "Is Secure DNS complete?" so that the working >group can know a priori and on nontechnical grounds whether to continue >accepting new work items in this area. > >(Note that I have personally quashed three mindblowingly better solutions >to things that DNSSEC got wrong, because at some point you have to cut and >print.) (Also note that I've been working on Secure DNS for close to 15 >years now, and the apparent endlessness of it is starting to get on my >nerves, and is NOT a simple artifact of protocol quality, which is why I'm >indicting the engineering mindset prevalant in the DNSEXT working group.) > >Paul Vixie Dear Paul, Perhaps people do not want Secure DNS; they want secure enough internet. In my personal opinion, DNSSEC is completely overkill solution to this problem, hard to maintain and functions as job security instrument.=20 EDNS, 0x20 etc. provide simple way of gaining sufficient security and would solve the major issues introduced by Kaminsky. I fail to see the rationale of taking DNSSEC into use. It would increase the amount of queries, amount of CPU power spent on calculating verifications. Yet in the same breath you complain other solutions spending intoleratable amount of bytes to gain the same practical solution.=20 I sympathize that you've spent 15+ years of time to get this thing off the ground, and I feel your frustration for your solution not being embraced globally. But, for all I can see, is that DNSSEC et al are just too heavy and overcomplicated solution to this problem. Perhaps more focus should be placed into "secure internet" than "secure DNS", which seems to be the trend now. In my opinion, DNSSEC and others are the overshoot.=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 Apr 23 13:54:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41393A684B; Thu, 23 Apr 2009 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_HTML_URI_LHOST31=1.666] 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 wjkWrcfnmPSI; Thu, 23 Apr 2009 13:53:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 695EA3A68AC; Thu, 23 Apr 2009 13:53:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5tM-000Mdg-IC for namedroppers-data0@psg.com; Thu, 23 Apr 2009 20:51:32 +0000 Received: from [194.100.2.122] (helo=smtp2.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx5t0-000MbC-SX for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 20:51:24 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp2.tdc.fi (Postfix) with ESMTP id AF36F6B1996 for ; Thu, 23 Apr 2009 23:51:09 +0300 (EEST) Content-class: urn:content-classes:message Subject: RE: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Apr 2009 23:37:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F13F27B5A@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Thread-Index: AcnEUvU+Gkq4WLsNSyqwoaKsKkfnAwAABoOA References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B52@fi-hel2ex01.nordiclan.net> <49F0D0E1.8040504@ca.afilias.info> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: >-----Original Message----- >From: Shane Kerr [mailto:shane@ca.afilias.info]=20 >Sent: Thursday, April 23, 2009 11:35 PM >To: Aki Tuomi >Cc: namedroppers@ops.ietf.org >Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt >EDNS0 Ping, benefits vs disadvantages ? > >Aki, > >Aki Tuomi wrote: >>>>> There is another cost for the authoritative server which did not >>>>> upgrade to edns-ping: an increase in the number of queries by >>>>> edns-ping resolvers trying to find out if there was a downgrade >>> attack >>>>> or if the authoritative server really does not support edns-ping. >>> Not >>>>> a big problem, IMHO, but it should be mentioned for completeness. >>>>> >>>>> >>>> I think any solution suffers from this drawback, not just EDNS0 PING. >>> Not necessarily. >>> >>> One idea is registering what features a name server supports in the >>> DNS(*). >>> >>> So, one could: >>> >>> * create a new RTYPE to encode which EDNS0 options were supported >>> * create a new EDNS0 option which the parent server would use to >>> report EDNS0 support from child records (as documented in the RTYPE) >>> >>> So, as the operator of TIME-TRAVELLERS.ORG, my zone might have: >>> >>> time-travellers.org. NS ns1.time-travellers.org. >>> NS ns2.time-travellers.org. >>> ns1.time-travellers.org A 1.2.3.4 >>> EDNS0OPT ( NSID PING ) >>> ns2.time-travellers.org A 2.3.4.5 >>> EDNS0OPT ( NSID PING ) >>> >>> The EDNS0OPT would be a new type of glue. >>> >>> -- >>> Shane >>> >>> (*) This idea occurs to me after looking at DNSCurve. DNScurve encodes >>> a >>> public key in the NS set for a zone. So your NS set may be: >>> >>> example.com NS d4fdfsu8j3j331234faes32aaasdfGG.example.com >>> NS lkj4444lkjsadfo89unasdfnasdlqu1.example.com >>> >>> A clever idea, and one that can be extended here. >>>=20 >> Yes, which requires extra requests. You still have to (periodically) >query the other party. Probably quite often. So there is still no free >lunch.=20 >The idea is that this information would get passed along in the replies >to queries via a new EDNS0 option; no extra queries would be required to >get this information. Now that might not be a practical idea, but in >theory it can work. :) >I don't think there are extra requests. Certainly not for the DNSCurve, >and I think not for registering EDNS0 Ping support within the DNS >(although again, it's all quite vague without solid descriptions at this >point... I guess I'll have to hammer out a draft). > >-- >Shane Point of EDNS PING is to send 'nonce' along the query. Then the other party will reply with the 'nonce' in the return packet, if supported.=20 You'd have to do extra queries after receiving the EDNS OPTION RR, to do this exchange.=20 --- Aki Tuomi -- to unsubscribe send a message to namedroppers-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 Apr 23 14:06:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4EA3A7318; Thu, 23 Apr 2009 14:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 UeHRm+WCqPom; Thu, 23 Apr 2009 14:06:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 731383A7315; Thu, 23 Apr 2009 14:06:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx64z-000ODy-G2 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 21:03:33 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx64j-000OBK-B3 for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 21:03:26 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 742972FE960A for ; Thu, 23 Apr 2009 21:03:16 +0000 (UTC) Date: Thu, 23 Apr 2009 17:03:14 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090423210314.GL68912@shinkuro.com> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 07:29:05AM -0700, Nicholas Weaver wrote: > > No. The recursor itself IS the untrustworthy part! In the presence of a secured stub-recursor connection, that reduces to either "if you don't trust your ISP, you're in deep trouble" or "if someone can redirect all your DNS queries, you're hosed". Since the latter reduces to "if someone has superuser access, you're hosed", I agree. It seems to me that if someone can rewrite your /etc/resolv.conf in such a way as the latter case, then they can just as easily install new root-zone keys and send you to any servers they like. So that's not a thing we're going to be able to protect against in any case. So it's not interesting. What remains, then, is whether there is a problem we can solve if your ISP can't be trusted. Right? -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 23 14:18:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CD73A68E5; Thu, 23 Apr 2009 14:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.342 X-Spam-Level: X-Spam-Status: No, score=-5.342 tagged_above=-999 required=5 tests=[AWL=-0.294, 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 4WO8lj-8-pbe; Thu, 23 Apr 2009 14:18:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E2A43A67B6; Thu, 23 Apr 2009 14:18:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6HJ-000Pxy-H8 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 21:16:17 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6H7-000PwJ-0X for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 21:16:10 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3NLG4O1004160; Thu, 23 Apr 2009 14:16:04 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <70200DB8-BB0B-49A6-96BF-C849DA491AAE@icsi.berkeley.edu> From: Nicholas Weaver To: Andrew Sullivan In-Reply-To: <20090423204048.GJ68912@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] we need an IAB statement on Secure DNS Date: Thu, 23 Apr 2009 14:16:03 -0700 References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> <20090423204048.GJ68912@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 1:40 PM, Andrew Sullivan wrote: > > >> Since we are obviously lacking DEPLOYED end-to-end integrity >> mechanisms >> for DNS, it is important that we ensure hop-by-hop protection against >> out-of-path adversaries with protection of 1 in 2^40 (minimum), 1 >> in 2^64 >> (ideal), with changes that are code-only: no changes to authority or >> resolver management but only the code running on those servers. > > I have doubts that large DNS operators, when confronted with > as-yet-unknown changes to their traffic patterns due to these > alternative techniques, will really regard this as a code-only change. I would say that this HAS been validated for 0x20: The widespread survey of Dagon et al for the CCS paper, plus manual intervention in the one high-profile non-deployer (google is now 0x20 compliant), shows that 0x20 is indeed a resolver only, code only change. A similar survey should be conducted for EDNS0-ping, (i've suggested as much to the authors) to see how the existing authority population, already deployed, will react. It also appears plausible to do a survey of authority load: Send a short burst of queries to an authority, should hopefully find any bottlenecks in the network and the capacity of those bottlenecks. You can indeed validate many such proposed changes in this manner. -- to unsubscribe send a message to namedroppers-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 Apr 23 14:39:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6BCB3A7315; Thu, 23 Apr 2009 14:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.482, 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 XhD3IkdRatLg; Thu, 23 Apr 2009 14:39:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CED9A3A6E7F; Thu, 23 Apr 2009 14:39:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6b9-0002I7-Cu for namedroppers-data0@psg.com; Thu, 23 Apr 2009 21:36:47 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6aw-0002Gz-6D for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 21:36:40 +0000 Received: by ewy2 with SMTP id 2so761900ewy.41 for ; Thu, 23 Apr 2009 14:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=/ivIu6EE6m0uO1Jj+bFD6xtEwUqVoJNwEKwr180qO5A=; b=akldGbAI/ei3JvLzgl/mcEobc+hn79WHswNEKqsq9aTUpEQdSkPzQ4eJ3g8o3ay/38 TxVOP++yLneN4TrB9Gj+TX6FlvHWH0if8nRTl8bH+pkeE2QVj4nGFJDmeAHnub0Cz3AT i4+hAr2o2SkoxF9ByNv/g5hcOSALyk8MW71yU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=xVlGsKkDjFbd6J1xDXFE5jeyuuEa+qz77snzuYHgC7tkRkmp8WnePa+av5lse0vxBZ i7hkIG7kNHPP61WruTZb/B5A6VUOyOLdY5KNi+Vvi/8vGCKzELOWYOC+xokD7CNze/rD D42GM34TklnnAlNvAXUJy7sx+jAzah7QDeIsc= MIME-Version: 1.0 Received: by 10.210.86.10 with SMTP id j10mr501029ebb.0.1240522593082; Thu, 23 Apr 2009 14:36:33 -0700 (PDT) In-Reply-To: <70200DB8-BB0B-49A6-96BF-C849DA491AAE@icsi.berkeley.edu> References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> <20090423204048.GJ68912@shinkuro.com> <70200DB8-BB0B-49A6-96BF-C849DA491AAE@icsi.berkeley.edu> From: bert hubert Date: Thu, 23 Apr 2009 23:36:18 +0200 Message-ID: <3efd34cc0904231436h24fcbf4eo34b84ad795e5cbdf@mail.gmail.com> Subject: Re: [dnsext] we need an IAB statement on Secure DNS To: Nicholas Weaver Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 11:16 PM, Nicholas Weaver wrote: > A similar survey should be conducted for EDNS0-ping, (i've suggested as m= uch > to the authors) to see how the existing authority population, already > deployed, will react. This is in progress. I've just contacted the last major source of EDNS0 problems, and I've been assured they'll look into it. In addition, it turned out to be possible to work around the F5 problem from the resolver side. I am actively replaying the billions of packets various access providers have donated, and comparing the pre- and post EDNS-ping results. I will post these soon. > It also appears plausible to do a survey of authority load: =A0Send a sho= rt > burst of queries to an authority, should hopefully find any bottlenecks i= n > the network and the capacity of those bottlenecks. The overhead of an EDNS-PING is 8 bytes btw. Bert -- to unsubscribe send a message to namedroppers-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 Apr 23 14:39:51 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCAC3A7315; Thu, 23 Apr 2009 14:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.334 X-Spam-Level: X-Spam-Status: No, score=-5.334 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 PtaFlq6muKDr; Thu, 23 Apr 2009 14:39:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53B9D3A6E7F; Thu, 23 Apr 2009 14:39:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6cm-0002Q2-J5 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 21:38:28 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6ca-0002P3-9d for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 21:38:22 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3NLcD7L006349; Thu, 23 Apr 2009 14:38:13 -0700 (PDT) Cc: Nicholas Weaver , Andrew Sullivan , namedroppers@ops.ietf.org Message-Id: <68272DC4-243D-42BB-A010-C8379C775C75@ICSI.Berkeley.EDU> From: Nicholas Weaver To: bert hubert In-Reply-To: <3efd34cc0904231436h24fcbf4eo34b84ad795e5cbdf@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] we need an IAB statement on Secure DNS Date: Thu, 23 Apr 2009 14:38:13 -0700 References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> <20090423204048.GJ68912@shinkuro.com> <70200DB8-BB0B-49A6-96BF-C849DA491AAE@icsi.berkeley.edu> <3efd34cc0904231436h24fcbf4eo34b84ad795e5cbdf@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 2:36 PM, bert hubert wrote: > On Thu, Apr 23, 2009 at 11:16 PM, Nicholas Weaver > wrote: >> A similar survey should be conducted for EDNS0-ping, (i've >> suggested as much >> to the authors) to see how the existing authority population, already >> deployed, will react. > > This is in progress. I've just contacted the last major source of > EDNS0 problems, and I've been assured they'll look into it. > > In addition, it turned out to be possible to work around the F5 > problem from the resolver side. > > I am actively replaying the billions of packets various access > providers have donated, and comparing the pre- and post EDNS-ping > results. I will post these soon. Excellent. > > >> It also appears plausible to do a survey of authority load: Send a >> short >> burst of queries to an authority, should hopefully find any >> bottlenecks in >> the network and the capacity of those bottlenecks. > > The overhead of an EDNS-PING is 8 bytes btw. What is the fallback position, however? EDNS-PING may be small, but when an authority does not support it, then what? -- to unsubscribe send a message to namedroppers-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 Apr 23 14:40:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1D73A684B; Thu, 23 Apr 2009 14:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.38 X-Spam-Level: *** X-Spam-Status: No, score=3.38 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 R1Nlol6LOO55; Thu, 23 Apr 2009 14:40:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB72D3A681D; Thu, 23 Apr 2009 14:40:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6du-0002dI-IN for namedroppers-data0@psg.com; Thu, 23 Apr 2009 21:39:38 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6di-0002Zv-0Z for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 21:39:32 +0000 Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Lx6dh-0004mq-Bi for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 22:39:25 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1Lx6dg-0007o3-T7 for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 22:39:24 +0100 Message-ID: From: "George Barwood" To: References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> <3efd34cc0904230840l18c96a35lba7e67adfd540b6d@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949C4F2CD@KAEVS1.SIDN.local> Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Thu, 23 Apr 2009 22:39:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Antoin Verschuren" To: Sent: Thursday, April 23, 2009 6:50 PM Subject: RE: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? > And speaking of traffic, yes that's my greatest worry too. I think every > bit counts. You should be aware that if EDNS Ping ( or equivalent ) is not introduced, traffic may at some point increase as clients deploy repeated requests to obtain security against spoofing. It's impossible to predict when this might happen, but EDNS Ping provides a pre-engineered solution. Therefore if you are concerned about every bit, you should support EDNS Ping. -- to unsubscribe send a message to namedroppers-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 Apr 23 14:47:11 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515473A6E09; Thu, 23 Apr 2009 14:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.496 X-Spam-Level: X-Spam-Status: No, score=-4.496 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_51=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 uXRhTidu6exB; Thu, 23 Apr 2009 14:47:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E2F13A6E7F; Thu, 23 Apr 2009 14:45:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6iI-00031Z-CD for namedroppers-data0@psg.com; Thu, 23 Apr 2009 21:44:10 +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 1Lx6i4-00030n-7v for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 21:44:03 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n3NLgr8x032635; Thu, 23 Apr 2009 21:42:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n3NLgmIE032634; Thu, 23 Apr 2009 21:42:48 GMT Date: Thu, 23 Apr 2009 21:42:48 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090423214248.GB32543@vacation.karoshi.com.> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090423210314.GL68912@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 05:03:14PM -0400, Andrew Sullivan wrote: > On Thu, Apr 23, 2009 at 07:29:05AM -0700, Nicholas Weaver wrote: > > > > No. The recursor itself IS the untrustworthy part! > > In the presence of a secured stub-recursor connection, that reduces to > either "if you don't trust your ISP, you're in deep trouble" or "if > someone can redirect all your DNS queries, you're hosed". Since the > latter reduces to "if someone has superuser access, you're hosed", I > agree. > > It seems to me that if someone can rewrite your /etc/resolv.conf in > such a way as the latter case, then they can just as easily install > new root-zone keys and send you to any servers they like. So that's > not a thing we're going to be able to protect against in any case. So > it's not interesting. > > What remains, then, is whether there is a problem we can solve if your > ISP can't be trusted. Right? i think this is way over simplified. the only ISP i trust implicitly is the one servicing my house.. (in the immortal words of King Louie... "Thats ME!") now my laptop is mobile (designed for it), granted not as mobile as it used to be, but there you go. Do I trust my school network? heck no... there are network researchers on it. the contract sites I visit? only to the extent I have to. IETF network... hardly. They're as bad or worse than the school net. Hotels? Airports? Your house? Absolutely not. Untrustworthy ISP all. so what do I do? carry around a full-blown DNS IMR/Validator with my own set of keys. Yes, I'll end up getting an IP address from your handy DHCP/RA server (and apparently a bunch'o'worthless crap that I'll either dump or quarentine) ... And I'll happily build an IPSEC tunnel back to a trusted environment and go from there if you try and box me in. (Thanks Sam for pointing out how to run IP over DNS and Steve for how to run IP over HTTP) What young Nicholas might be touchy about goes back to the RVA discussions we held in sidebar IETFs about four years ago. One outcome was Suresh's ID on a DNSSEC API. ... :) --bill > > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 23 15:03:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933B93A6BC0; Thu, 23 Apr 2009 15:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.323 X-Spam-Level: ** X-Spam-Status: No, score=2.323 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RCVD_IN_NJABL_PROXY=1.643, 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 nOZeRrsKNcIX; Thu, 23 Apr 2009 15:03:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC3693A6DCC; Thu, 23 Apr 2009 15:01:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6wG-00057o-PT for namedroppers-data0@psg.com; Thu, 23 Apr 2009 21:58:36 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx6w4-000571-Hi for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 21:58:30 +0000 Received: (qmail 86811 invoked from network); 23 Apr 2009 23:16:35 -0000 Received: from softbank219001188013.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.13) by necom830.hpcl.titech.ac.jp with SMTP; 23 Apr 2009 23:16:35 -0000 Message-ID: <49F0E443.8010904@necom830.hpcl.titech.ac.jp> Date: Fri, 24 Apr 2009 06:57:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS References: <26249.1240510804@nsa.vix.com> In-Reply-To: <26249.1240510804@nsa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Paul Vixie wrote: > Chairs, please invoke some kind of review process by the IAB so that we can > get some direction on Secure DNS. We've got TSIG and TKEY and GSS TSIG and > SIG(0), and we've got DNSSEC, and we've got SPR. To me that's enough, it's > a complete system supporting both end to end (DNSSEC) and hop by hop (SPR, > TSIG, or or TKEY+SIG(0)) security. Wrong. DNSSEC is not secure end to end and is useless. DNSSEC is secure, at most, zone hop by zone hop, which is as secure as plain old DNS with NZ hop by NS hop security. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 23 15:12:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5673A6DCC; Thu, 23 Apr 2009 15:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[AWL=-0.656, 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 5Y0bZWlTNLuY; Thu, 23 Apr 2009 15:12:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A1993A68E5; Thu, 23 Apr 2009 15:12:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx77V-0006QX-F4 for namedroppers-data0@psg.com; Thu, 23 Apr 2009 22:10:13 +0000 Received: from [64.18.14.201] (helo=chip3og62.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx77I-0006PB-Ru for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 22:10:07 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSfDnNhKL9V/MhHV0UMQm0uSckLNnvk4l@postini.com; Thu, 23 Apr 2009 15:10:00 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5747A1B8374; Thu, 23 Apr 2009 15:10:12 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 23 Apr 2009 15:09:57 -0700 CC: Namedroppers WG Message-ID: From: Ted Lemon To: Nicholas Weaver In-Reply-To: <88CBC7F8-51A2-4A2C-8F21-B1F0094E1608@ICSI.Berkeley.EDU> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] we need an IAB statement on Secure DNS Date: Thu, 23 Apr 2009 17:09:55 -0500 References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> <88CBC7F8-51A2-4A2C-8F21-B1F0094E1608@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 3:48 PM, Nicholas Weaver wrote: > But if the final application is not end-to-end seceure, who cares if > the name->address mapping is correct when the already in-path > adversary can directly attack the final application? So suppose I'm in-path between you and some portion of the DNS, and I succeed in convincing you that www.bankofmordor.com is at 123.45.67.89. Even though I don't control the path between you and bankofmordor.com, I can still get your traffic to bankofmordor.com, because I've managed to control your DNS. Just because DNS traffic goes through a suborned path, does not mean that all traffic goes through a suborned path. And vice versa. So it makes sense to protect both. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 23 15:17:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EAF28C185; Thu, 23 Apr 2009 15:17:18 -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 OOB23qWnxIM3; Thu, 23 Apr 2009 15:17:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A826A28C127; Thu, 23 Apr 2009 15:17:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx7CV-0006vb-Dr for namedroppers-data0@psg.com; Thu, 23 Apr 2009 22:15:23 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx7CC-0006sn-D1 for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 22:15:16 +0000 Received: by ewy2 with SMTP id 2so773570ewy.41 for ; Thu, 23 Apr 2009 15:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8aijDKI3MOsQXpYLOWGZZU0itaOcVnjI+QwSDf3OyK0=; b=xDXUSOxKTQaYRqWaSAhnU67LXVLFnV5LG7dZE76NyQtTved0yETK5FJlZXFXp3Icnw Ga0HKbHuTwCH1+OHVRmACoyoRXQwCnRpZ7AtWPSZuq6RGrTgskd30rO+FFOQeCU71y+f DbUplv3DJrtaoYjOsHTZpBlpE3PN+0B8Cwzd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=tXXRC+OfLFDv815rR+UJH5ZrwTPFGn20xIN7aCFEVrvoZ4JvjcpkOC2IpZCOYRZyTw WKHhRAx1/fwa+fh30AuhwTaNRbkFpY0ncYGhlb4M98zrFaEv2dK6iDAZ/WLUrrE3EP07 pxevYtjunzRrapvAI9tWUSV/ElmHlLqxV6HcQ= MIME-Version: 1.0 Received: by 10.210.13.17 with SMTP id 17mr505183ebm.43.1240524902186; Thu, 23 Apr 2009 15:15:02 -0700 (PDT) In-Reply-To: <68272DC4-243D-42BB-A010-C8379C775C75@ICSI.Berkeley.EDU> References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> <20090423204048.GJ68912@shinkuro.com> <70200DB8-BB0B-49A6-96BF-C849DA491AAE@icsi.berkeley.edu> <3efd34cc0904231436h24fcbf4eo34b84ad795e5cbdf@mail.gmail.com> <68272DC4-243D-42BB-A010-C8379C775C75@ICSI.Berkeley.EDU> From: bert hubert Date: Fri, 24 Apr 2009 00:14:47 +0200 Message-ID: <3efd34cc0904231514o7f701258oe80ee830941aa30f@mail.gmail.com> Subject: Re: [dnsext] we need an IAB statement on Secure DNS To: Nicholas Weaver Cc: Andrew Sullivan , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 11:38 PM, Nicholas Weaver wrote: >> I am actively replaying the billions of packets various access >> providers have donated, and comparing the pre- and post EDNS-ping >> results. I will post these soon. > > Excellent. People might notice - my testing from one server replays the traffic in realtime as recorded from several million customers. >> The overhead of an EDNS-PING is 8 bytes btw. > > What is the fallback position, however? =A0EDNS-PING may be small, but wh= en an > authority does not support it, then what? It is my personal opinion that the fallback position is entirely up to the implementor. Conceivably, you might not even have one. If you do the math, it is not overly easy to spoof a suitably source port randomized server - see http://blog.netherlabs.nl/articles/2008/08/05/calculating-the-chance-of-spo= ofing-an-agile-source-port-randomised-resolver Bert -- to unsubscribe send a message to namedroppers-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 Apr 23 15:46:55 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107D43A6FA1; Thu, 23 Apr 2009 15:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, IP_NOT_FRIENDLY=0.334, 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 jxTGm7BKO223; Thu, 23 Apr 2009 15:46:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74D8D28C2FC; Thu, 23 Apr 2009 15:46:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx7d5-0009aF-HA for namedroppers-data0@psg.com; Thu, 23 Apr 2009 22:42:51 +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 1Lx7ct-0009Zd-RB for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 22:42:45 +0000 Message-ID: <49F0EEDB.40900@ca.afilias.info> Date: Fri, 24 Apr 2009 00:42:35 +0200 From: Shane Kerr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Aki Tuomi CC: namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B52@fi-hel2ex01.nordiclan.net> <49F0D0E1.8040504@ca.afilias.info> <86048CA3B4B17E459FFD4F3F383AD88F13F27B5A@fi-hel2ex01.nordiclan.net> In-Reply-To: <86048CA3B4B17E459FFD4F3F383AD88F13F27B5A@fi-hel2ex01.nordiclan.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Authenticated: True Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Aki, Aki Tuomi wrote: > Point of EDNS PING is to send 'nonce' along the query. Then the other > party will reply with the 'nonce' in the return packet, if supported. > > You'd have to do extra queries after receiving the EDNS OPTION RR, to do > this exchange. No, the idea is to get this information when determining the IP address(es) of the NS entry. This can possibly be done by adding it to the ADDITIONAL section, or maybe by encoding it in an EDNS0 option. -- 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 Thu Apr 23 16:10:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C37E3A6B3E; Thu, 23 Apr 2009 16:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.955 X-Spam-Level: X-Spam-Status: No, score=-98.955 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 Wv0aOrGYdBcA; Thu, 23 Apr 2009 16:10:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59FAD3A69F2; Thu, 23 Apr 2009 16:10:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx7z0-000CGV-PM for namedroppers-data0@psg.com; Thu, 23 Apr 2009 23:05:30 +0000 Received: from [208.109.78.207] (helo=smtpoutwbe05.prod.mesa1.secureserver.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx7yi-000CCg-GA for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 23:05:21 +0000 Received: (qmail 25399 invoked from network); 23 Apr 2009 23:05:11 -0000 Received: from unknown (HELO gem-wbe09.prod.mesa1.secureserver.net) (64.202.189.48) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 23 Apr 2009 23:05:10 -0000 Received: (qmail 24179 invoked by uid 99); 23 Apr 2009 23:05:10 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 172.19.38.137 User-Agent: Web-Based Email 5.0.10 Message-Id: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> From: To: namedroppers@ops.ietf.org Subject: RE: [dnsext] we need an IAB statement on Secure DNS Date: Thu, 23 Apr 2009 16:05:10 -0700 Mime-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I'm not entirely sure what qualifies one as a "large DNS operator", but based on my current understanding of the proposal, I do not anticipate operational changes to support EDNS-PING within my organization.=20 However, I must have missed the large operator's concern that you mentioned. If you could point me in the right direction on that, I would appreciate it. ---- Joe Miller GoDaddy.com jmiller@godaddy.com 480.505.8800 x4430 -------- Original Message -------- Subject: Re: [dnsext] we need an IAB statement on Secure DNS From: Andrew Sullivan Date: Thu, April 23, 2009 1:40 pm To: namedroppers@ops.ietf.org =20 =20 I have doubts that large DNS operators, when confronted with as-yet-unknown changes to their traffic patterns due to these alternative techniques, will really regard this as a code-only change. In places I have worked with operations on any scale, extensions to any protocol automatically entailed changes to operations. At the very least, I'd bet a number of monitors in some sites would have to be adjusted. I am therefore quite sceptical of claims that the proposed techniques are a code-only change. We hear one large operator expressing doubts also; it would be valuable to me to have informed input from other operators as to whether they regard the proposed techniques (to the extent they are completely defined) as a code-only change, or whether they think the techniques might impose operations changes too. =20 Again, just my personal opinion. =20 A =20 --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. =20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-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 Apr 23 16:40:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDC528C107; Thu, 23 Apr 2009 16:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=0.840, 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 J3QU-DTzyqLC; Thu, 23 Apr 2009 16:40:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0F683A6E05; Thu, 23 Apr 2009 16:40:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx8UZ-000FUq-FQ for namedroppers-data0@psg.com; Thu, 23 Apr 2009 23:38:07 +0000 Received: from [209.86.89.66] (helo=elasmtp-spurfowl.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx8UI-000FTz-EE for namedroppers@ops.ietf.org; Thu, 23 Apr 2009 23:38:01 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=KMgnNZixJLvJ29gxriWPS1qzTrLinC8DFpp9m7uFjBMYv2wsBu2uIsOA0cTi7NIl; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.102.206] (helo=ix.netcom.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lx8UD-0001vQ-0w; Thu, 23 Apr 2009 19:37:46 -0400 Message-ID: <49F0FBC1.BB314149@ix.netcom.com> Date: Thu, 23 Apr 2009 16:37:37 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicholas Weaver CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688d35248ff838a4b81a537afcbe17c965b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.102.206 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Nicholas and all, Reluctantly I agree with your view Nick. But I am sure you know that sooner rather than later governmental folks will question such an approach. Nicholas Weaver wrote: > On Apr 23, 2009, at 11:20 AM, Paul Vixie wrote: > > > Chairs, please invoke some kind of review process by the IAB so that > > we can > > get some direction on Secure DNS. We've got TSIG and TKEY and GSS > > TSIG and > > SIG(0), and we've got DNSSEC, and we've got SPR. To me that's > > enough, it's > > a complete system supporting both end to end (DNSSEC) and hop by hop > > (SPR, > > TSIG, or or TKEY+SIG(0)) security. However, the engineering mindset > > that > > dominates this working group is now way into its customary overshoot > > (DNS-0x20, EDNS PING, cookies) and there is at least one major > > non-working-group project (dnscurve) in the works. > > Actually, I'd argue differently, as someone who wants a secure > Internet, not "Secure DNS": > > Hop by hop cryptographic protection is unnecessary and unuseful for > general purposes (as opposed to distributing zone files or similar > within a group of systems, which is what TSIG is for, but an SSH > tunnel works just as well...). > > Hop by hop protections only need to protect against out-of-path > attackers, as the one key in-path attacker is the recursive resolver > itself, which hop to hop protections do not defend against. > > Yet hop-by-hop cryptographic systems have all the problems otherwise > associated with cryptographic systems, including key management, > changes to authority management, etc etc etc. > > Thus I believe "Secure" DNS should consider... > > A) Hop-by-hop protection against out-of-path attackers ONLY. Such > protection should be deployable with changes to only the code base of > the authorities and/or resolvers, NOT the management of the systems. > > This is why 0x20 and EDNS0 Ping are so attractive, and why I believe > that TKEY+SIG(0), dnscurve, etc, are just fine thrown in the trash can > for general use. > > In fact, general cryptographic protections for hop-by-hop data for DNS > are WORSE than useless: they provide an illusion of "security", > without providing a significant increase in system security in most > cases. [1] > > B) End-to-end cryptographic protection, validated by the END HOST > (not the recursive resolver), targeted at authenticating Name->data > mappings for application use (mostly for keys), not Name->Address > mappings [2]. > > A is 0x20 and EDNS0-ping. B is DNSSEC with a better API and some > usage conventions. > > > (Note that I have personally quashed three mindblowingly better > > solutions > > to things that DNSSEC got wrong, because at some point you have to > > cut and > > print.) (Also note that I've been working on Secure DNS for close > > to 15 > > years now, and the apparent endlessness of it is starting to get on my > > nerves, and is NOT a simple artifact of protocol quality, which is > > why I'm > > indicting the engineering mindset prevalant in the DNSEXT working > > group.) > > And at the same time, I'm not willing to sacrifice achievable and > deployable protection against out-of-path adversaries today for the > hope of protection against in-path adversaries tomorrow. > > 0x20 and EDNS0-ping should not be obstacles for DNSSEC deployment, and > if they are viewed as obstacles by some, this is reflecting poorly on > DNSSEC's value proposition. DNSSEC has had years to try to win > adoption in the market. > > So I'd personally state: > > End to end integrity for name->data mappings is the goal. DNSSEC, if > deployed, provides this. > > Since we are obviously lacking DEPLOYED end-to-end integrity > mechanisms for DNS, it is important that we ensure hop-by-hop > protection against out-of-path adversaries with protection of 1 in > 2^40 (minimum), 1 in 2^64 (ideal), with changes that are code-only: no > changes to authority or resolver management but only the code running > on those servers. > > So yes, by all means do a review process. > > But such a review should include use cases and deployability concerns. > > It should not be "If this all was deployed.." but also > "Why isn't the existing stuff deployed?" > and > "Should we do something less if it can be deployed today?" > > [1] In the same boat goes DNSSEC validation on the recursive > resolver. Validating DNSSEC at the recursive resolver offers > effectively NO security benefits, and IMO, that model should be > discarded. > > If I'm able to do in-path attacks on the DNS packets between the > authority and the recursive resolver, I'm probably able to do the same > attack on the user's TCP connections (see http://lists.immunitysec.com/pipermail/dailydave/2009-March/005601.html > ) > > [2] I can always get "as secure as my network is for the data itself" > name->address mappings by simply generating my own iterative request. > And the externality of such behavior doesn't affect me, just the > authorities. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-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 Apr 23 18:08:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7E528C545; Thu, 23 Apr 2009 18:08:26 -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 Cu2w-y4QC1T6; Thu, 23 Apr 2009 18:08:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 73B133A6A17; Thu, 23 Apr 2009 18:08:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx9pc-000Oc4-5I for namedroppers-data0@psg.com; Fri, 24 Apr 2009 01:03:56 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lx9pO-000ObO-Qv for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 01:03:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4CDBCA105B; Fri, 24 Apr 2009 01:03:36 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "Aki Tuomi" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS In-Reply-To: Your message of "Thu, 23 Apr 2009 23:27:18 +0300." <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> References: <26249.1240510804@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 24 Apr 2009 01:03:36 +0000 Message-ID: <44750.1240535016@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Thu, 23 Apr 2009 23:27:18 +0300 > From: "Aki Tuomi" > > Perhaps people do not want Secure DNS; they want secure enough internet. > In my personal opinion, DNSSEC is completely overkill solution to this > problem, hard to maintain and functions as job security instrument. ... it may be as you say. let's find out. this working group was rechartered some years ago to take on the remaining work of the old DNSSEC WG, among which was to finish defining DNSSEC and making it deployable. now that i have seen it take more than a decade to make IPv6 market-ready and so far one and a half decades to make DNSSEC market-ready, i understand current events in the following context. 1. almost everybody is bored stiff by the never-ending secure dns work. 2. almost nobody remembers what we're doing or why, or signed up for it. 3. almost everybody can think of better ways to do some/all of Secure DNS. 4. many people have smaller needs than what the Secure DNS vision addresses. 5. cool new technology like elliptic curve looks a lot more interesting. i mention these contextual elements in case it seems like i don't "get it." but, Secure DNS is a multigenerational project -- the engineers who started it will in many cases retire or take a different project before it's finished. that requires some discipline. i'm not saying that folks who want a secure internet shouldn't have one! i am saying that "we" started this and "we" should either finish it or abandon it BEFORE we start a whole bunch of potentially competing/overlapping work. so i'm calling for some adult supervision to help get us / keep us on track. -- to unsubscribe send a message to namedroppers-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 Apr 23 20:30:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19943A6A29; Thu, 23 Apr 2009 20:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.096 X-Spam-Level: X-Spam-Status: No, score=-5.096 tagged_above=-999 required=5 tests=[AWL=-0.601, 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 UwSni281a3cZ; Thu, 23 Apr 2009 20:30:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC72A3A6A10; Thu, 23 Apr 2009 20:30:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxC25-000Any-FL for namedroppers-data0@psg.com; Fri, 24 Apr 2009 03:24:57 +0000 Received: from [64.18.2.28] (helo=exprod7og125.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxC1t-000An1-2w for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 03:24:51 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSfEw+l/h6PeN+6n0uucZXpWMJAf/L5wg@postini.com; Thu, 23 Apr 2009 20:24:45 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 775F11B8374; Thu, 23 Apr 2009 20:24:56 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 23 Apr 2009 20:24:41 -0700 CC: Namedroppers WG Message-ID: <06996244-4EE1-4255-A277-C93BD20BB691@nominum.com> From: Ted Lemon To: Nicholas Weaver In-Reply-To: <94DAF04B-334B-464B-88AA-B4360936671D@ICSI.Berkeley.EDU> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] we need an IAB statement on Secure DNS Date: Thu, 23 Apr 2009 22:24:38 -0500 References: <26249.1240510804@nsa.vix.com> <83AEBCD7-21ED-4237-B3F8-A5405B90BEF9@icsi.berkeley.edu> <88CBC7F8-51A2-4A2C-8F21-B1F0094E1608@ICSI.Berkeley.EDU> <94DAF04B-334B-464B-88AA-B4360936671D@ICSI.Berkeley.EDU> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 23, 2009, at 9:00 PM, Nicholas Weaver wrote: > The cases where you are on the naming path but not the data path, > EXCEPT when you control the recursive resolver itself, are fairly far- > between. First of all, I don't have to suborn your cache. I can suborn one of the servers that publishes .COM. I can then attack selectively, only sending wrong data to certain high-value IP addresses, only for certain high-value NS records. I can send correct data to all others, so that the fact that I've got control over .COM is difficult to detect, even if you detect bad data in your cache. Are you prepared to say that this attack is impossible, or even unlikely? Even after the recent news about how criminals have been able to get ATM card PIN data using a very, very similar attack? I'm sorry, but that's naive. Secondly, resolvers often run on machines that can be rooted. It may be relatively easy, or relatively hard, to root one of these machines, as compared to gaining control over your ISP's routing infrastructure, but I think it's (again, forgive me) naive to suggest that there will not be situations where suborning your cache is easier or more cost- effective than suborning your routing infrastructure. Indeed, I would argue that this is very likely to be the case, since the IP address of your cache is public knowledge, and you probably have fewer caches than routers. Forgive me for being obstinate about this - you sound very convincing with your on-path versus off-path rationalizations. But on closer analysis, what you are really saying is that despite the alarmingly competent and successful attacks we've seen recently in the form of things like ATM PIN siphoning and the the recent analysis of the Conficker.C virus, it's still okay to use a low-effort, less-is-more approach to preventing attacks on the DNS. I don't think you want to become famous for championing this idea. -- to unsubscribe send a message to namedroppers-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 Apr 23 22:55:19 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576EF3A6ABC; Thu, 23 Apr 2009 22:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.51 X-Spam-Level: X-Spam-Status: No, score=-4.51 tagged_above=-999 required=5 tests=[AWL=0.538, 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 zyatvW4n+7mB; Thu, 23 Apr 2009 22:55:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5569B3A69FF; Thu, 23 Apr 2009 22:55:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxEJm-000OGO-Tg for namedroppers-data0@psg.com; Fri, 24 Apr 2009 05:51:22 +0000 Received: from [194.100.2.124] (helo=smtp1.tdc.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxEJa-000OE1-J4 for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 05:51:16 +0000 Received: from fi-hel2ex01.nordiclan.net (unknown [194.100.219.27]) by smtp1.tdc.fi (Postfix) with ESMTP id 4AA84581DA2 for ; Fri, 24 Apr 2009 08:51:09 +0300 (EEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [dnsext] we need an IAB statement on Secure DNS X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 24 Apr 2009 08:51:04 +0300 Message-ID: <86048CA3B4B17E459FFD4F3F383AD88F13F27B5B@fi-hel2ex01.nordiclan.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] we need an IAB statement on Secure DNS Thread-Index: AcnEeITY+nnpcMaoSjWZqK4nFRLFfAAJ5baQ References: <26249.1240510804@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> <44750.1240535016@nsa.vix.com> From: "Aki Tuomi" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2aXhpZUB2aXguY29tIFttYWls dG86dml4aWVAdml4LmNvbV0gT24gQmVoYWxmIE9mIFBhdWwgVml4aWUNCj4gU2VudDogRnJpZGF5 LCBBcHJpbCAyNCwgMjAwOSA0OjA0IEFNDQo+IFRvOiBBa2kgVHVvbWkNCj4gQ2M6IG5hbWVkcm9w cGVyc0BvcHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkbnNleHRdIHdlIG5lZWQgYW4gSUFC IHN0YXRlbWVudCBvbiBTZWN1cmUgRE5TDQo+IA0KPiA+IERhdGU6IFRodSwgMjMgQXByIDIwMDkg MjM6Mjc6MTggKzAzMDANCj4gPiBGcm9tOiAiQWtpIFR1b21pIiA8QWtpLlR1b21pQHRkYy5maT4N Cj4gPg0KPiA+IFBlcmhhcHMgcGVvcGxlIGRvIG5vdCB3YW50IFNlY3VyZSBETlM7IHRoZXkgd2Fu dCBzZWN1cmUgZW5vdWdoDQo+IGludGVybmV0Lg0KPiA+IEluIG15IHBlcnNvbmFsIG9waW5pb24s IEROU1NFQyBpcyBjb21wbGV0ZWx5IG92ZXJraWxsIHNvbHV0aW9uIHRvDQo+IHRoaXMNCj4gPiBw cm9ibGVtLCBoYXJkIHRvIG1haW50YWluIGFuZCBmdW5jdGlvbnMgYXMgam9iIHNlY3VyaXR5DQo+ IGluc3RydW1lbnQuICAuLi4NCj4gDQo+IGl0IG1heSBiZSBhcyB5b3Ugc2F5LiAgbGV0J3MgZmlu ZCBvdXQuICB0aGlzIHdvcmtpbmcgZ3JvdXAgd2FzDQo+IHJlY2hhcnRlcmVkDQo+IHNvbWUgeWVh cnMgYWdvIHRvIHRha2Ugb24gdGhlIHJlbWFpbmluZyB3b3JrIG9mIHRoZSBvbGQgRE5TU0VDIFdH LA0KPiBhbW9uZw0KPiB3aGljaCB3YXMgdG8gZmluaXNoIGRlZmluaW5nIEROU1NFQyBhbmQgbWFr aW5nIGl0IGRlcGxveWFibGUuICBub3cgdGhhdA0KPiBpDQo+IGhhdmUgc2VlbiBpdCB0YWtlIG1v cmUgdGhhbiBhIGRlY2FkZSB0byBtYWtlIElQdjYgbWFya2V0LXJlYWR5IGFuZCBzbw0KPiBmYXIN Cj4gb25lIGFuZCBhIGhhbGYgZGVjYWRlcyB0byBtYWtlIEROU1NFQyBtYXJrZXQtcmVhZHksIGkg dW5kZXJzdGFuZA0KPiBjdXJyZW50DQo+IGV2ZW50cyBpbiB0aGUgZm9sbG93aW5nIGNvbnRleHQu DQo+IA0KPiAxLiBhbG1vc3QgZXZlcnlib2R5IGlzIGJvcmVkIHN0aWZmIGJ5IHRoZSBuZXZlci1l bmRpbmcgc2VjdXJlIGRucyB3b3JrLg0KPiAyLiBhbG1vc3Qgbm9ib2R5IHJlbWVtYmVycyB3aGF0 IHdlJ3JlIGRvaW5nIG9yIHdoeSwgb3Igc2lnbmVkIHVwIGZvciBpdC4NCj4gMy4gYWxtb3N0IGV2 ZXJ5Ym9keSBjYW4gdGhpbmsgb2YgYmV0dGVyIHdheXMgdG8gZG8gc29tZS9hbGwgb2YgU2VjdXJl DQo+IEROUy4NCj4gNC4gbWFueSBwZW9wbGUgaGF2ZSBzbWFsbGVyIG5lZWRzIHRoYW4gd2hhdCB0 aGUgU2VjdXJlIEROUyB2aXNpb24NCj4gYWRkcmVzc2VzLg0KPiA1LiBjb29sIG5ldyB0ZWNobm9s b2d5IGxpa2UgZWxsaXB0aWMgY3VydmUgbG9va3MgYSBsb3QgbW9yZSBpbnRlcmVzdGluZy4NCj4g DQo+IGkgbWVudGlvbiB0aGVzZSBjb250ZXh0dWFsIGVsZW1lbnRzIGluIGNhc2UgaXQgc2VlbXMg bGlrZSBpIGRvbid0ICJnZXQNCj4gaXQuIg0KPiBidXQsIFNlY3VyZSBETlMgaXMgYSBtdWx0aWdl bmVyYXRpb25hbCBwcm9qZWN0IC0tIHRoZSBlbmdpbmVlcnMgd2hvDQo+IHN0YXJ0ZWQNCj4gaXQg d2lsbCBpbiBtYW55IGNhc2VzIHJldGlyZSBvciB0YWtlIGEgZGlmZmVyZW50IHByb2plY3QgYmVm b3JlIGl0J3MNCj4gZmluaXNoZWQuICB0aGF0IHJlcXVpcmVzIHNvbWUgZGlzY2lwbGluZS4gIGkn bSBub3Qgc2F5aW5nIHRoYXQgZm9sa3MNCj4gd2hvDQo+IHdhbnQgYSBzZWN1cmUgaW50ZXJuZXQg c2hvdWxkbid0IGhhdmUgb25lISAgaSBhbSBzYXlpbmcgdGhhdCAid2UiDQo+IHN0YXJ0ZWQNCj4g dGhpcyBhbmQgIndlIiBzaG91bGQgZWl0aGVyIGZpbmlzaCBpdCBvciBhYmFuZG9uIGl0IEJFRk9S RSB3ZSBzdGFydCBhDQo+IHdob2xlDQo+IGJ1bmNoIG9mIHBvdGVudGlhbGx5IGNvbXBldGluZy9v dmVybGFwcGluZyB3b3JrLg0KPiANCj4gc28gaSdtIGNhbGxpbmcgZm9yIHNvbWUgYWR1bHQgc3Vw ZXJ2aXNpb24gdG8gaGVscCBnZXQgdXMgLyBrZWVwIHVzIG9uDQo+IHRyYWNrLg0KDQpGaXJzdCBv ZiBhbGwsIEkgYWdyZWUsIGxldCdzIGZpbmQgb3V0LiBJIGFtIGFsbCBmb3IgYXNraW5nIHRoZSBj aGFpcnMgdG8gZXZhbHVhdGUuIFRoZSBtb3RpdmF0aW9uIGJlaGluZCBteSBpbml0aWFsIGVtYWls IHdhcyB0aGUgcGVyY2VpdmVkIGF0dGl0dWRlIGluIHlvdXIgZW1haWwgYXMgeW91IGJsYXRhbnRs eSBzdGF0ZWQgdGhhdCAiRE5OU0VDIGdvb2QsIG90aGVycyBiYWQiLiBUaGlzIGlzIGluZGVlZCB0 aGUgbWVzc2FnZSB5b3Ugc2VudCBieSBzdGF0aW5nIHRoYXQgdGhlIDB4MjAsIEVETlMgUElORywg RE5TQ3VydmUgZXRjLiBhcmUgImN1c3RvbWFyeSBvdmVyc2hvb3RpbmciLiBJdCB3b3VsZCBiZSBj b3VydGVvdXMgdG8gYXQgbGVhc3QgYWNrbm93bGVkZ2UgdGhhdCB0aGVzZSBhcmUgc2VyaW91cyBh dHRlbXB0cywgYW5kIG5vdCBqdXN0IHNvbWUgd2lzaHkgd2FzaHkgZW5naW5lZXJpbmcgYXR0ZW1w dCB0aGF0IHNob3VsZCBiZSByZWdhcmRlZCBhcyBubyBtb3JlIHRoYW4gbWVyZSBub2lzZS4gQXMg aW4sIHlvdSBjb3VsZCBoYXZlIGV4dGVuZGVkIGEgY291cnRlc3kgb2YgYWNrbm93bGVkZ2luZyB0 aGF0IHRoZXNlIGFyZSBzZXJpb3VzbHkgY29uc2lkZXJhYmxlIHNvbHV0aW9ucy4gDQoNCkJ1dCBJ IGFncmVlLiBTb21lIGFkdWx0IHN1cGVydmlzaW9uIHNlZW1zIHRvIGJlIG5lY2Vzc2FyeSB0byBj YWxtIGRvd24gYm90aCBwYXJ0aWVzLCBidXQgSSBqdXN0IGhvcGUgeW91J2Qgc2hvdyBzb21lIGNv dXJ0ZXN5IGFuZCByZXNwZWN0IHRvIHRoZSBvdGhlciBzdWdnZXN0ZWQgc29sdXRpb25zLCBpbnN0 ZWFkIG9mIGxhYmVsaW5nIHRoZW0gYXMgbm9pc2UuIA0KDQotLS0NCkFraSBUdW9taQ0K -- to unsubscribe send a message to namedroppers-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 Apr 24 00:34:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDFE28C6B5; Fri, 24 Apr 2009 00:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Rt7vKYTv8Ler; Fri, 24 Apr 2009 00:34:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A95C3A6F6F; Fri, 24 Apr 2009 00:34:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxFqX-0007Pz-OG for namedroppers-data0@psg.com; Fri, 24 Apr 2009 07:29:17 +0000 Received: from [2001:660:3003:2::4:11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxFqK-0007Nk-5o for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 07:29:10 +0000 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 096231C00F9; Fri, 24 Apr 2009 09:29:01 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 044FA1C00D9; Fri, 24 Apr 2009 09:29:01 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id ECE5BA1D9B7; Fri, 24 Apr 2009 09:29:00 +0200 (CEST) Date: Fri, 24 Apr 2009 09:29:00 +0200 From: Stephane Bortzmeyer To: Nicholas Weaver Cc: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" Subject: [dnsext] Re: Thinking about a DNSSEC api... Message-ID: <20090424072900.GA15262@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.1 X-Kernel: Linux 2.6.26-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 Thu, Apr 23, 2009 at 08:19:28AM -0700, Nicholas Weaver wrote a message of 132 lines which said: > gethostbyname() -> IP Address: Why the IPv4-only antediluvian gethostbyname and not RFC 3493? -- to unsubscribe send a message to namedroppers-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 Apr 24 03:07:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1C93A73AF; Fri, 24 Apr 2009 03:07: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=[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 pjP2or+De6QW; Fri, 24 Apr 2009 03:07:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C9183A6829; Fri, 24 Apr 2009 03:05:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxIDW-000O4d-Ns for namedroppers-data0@psg.com; Fri, 24 Apr 2009 10:01:10 +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 1LxIDH-000O3J-7I for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 10:01:03 +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.3/8.14.3) with ESMTP id n3OA0plY074378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2009 12:00:51 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <49F18DD3.5010508@nlnetlabs.nl> Date: Fri, 24 Apr 2009 12:00:51 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> <3efd34cc0904230840l18c96a35lba7e67adfd540b6d@mail.gmail.com> In-Reply-To: <3efd34cc0904230840l18c96a35lba7e67adfd540b6d@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 24 Apr 2009 12:00:51 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have asked questions too, and without answers on those topics, I do not think this draft can become a working group document. The reason those answers are needed is that the issues are important for security and interoperability. You note F5 interoperability concerns, and I think there may be interoperability issues using loadbalancers and different fallbacks. Going from the lab to the DNS world, there are surely many more. I believe that EDNS PING as specified in the current version of the draft is _not_ secure. Without documentation we cannot tell how to make it secure, and thoughts by me and others (expressed on this list, some as answers to my questions) are that EDNS PING suffers from severe downgrade problems. For a working group draft EDNS PING has to be convincingly an addition to security. Also I see deployment trouble, your words seem to indicate that you retry non-EDNS-PING server probes every hour, but EDNS-PING capable servers stay that way forever. This means that once deployed, a site can never ever change their server software or turn it off (once they have other security in place, DNScurve or DNSSEC)? Although I agree with Andreas that overspecification is bad, text is needed to advise implementors here. Based on the arguments above I believe that EDNS PING, as specified now, is (highly) experimental and not ready for standards track. In fact, as an implementor I will not implement the specification in the default configuration if the fallback mechanisms are not properly described, I believe that those lead to interoperability issues. I am willing to spend energy in the working group to review, ask critical questions, and consider solutions to problems. But, I've not yet been convinced that adding this extra bloat to the DNS, and the code base is worth the effort. I believe that ball is with the proposer to address these tough questions. Best regards, Wouter bert hubert wrote: > On Thu, Apr 23, 2009 at 5:03 PM, Paul Vixie wrote: >> thanks for correctly channeling my spirit. the other reasons i don't >> support adoption of cookies or edns-ping are: it adds a lot of complexity >> in order to solve a problem that we're not having (hop by hop corruption) > > We don't? I thought that this is what Kaminsky was all about.. > >> while failing to solve a problem we are having (end to end corruption); > > You appear to labour under the idea that the people who are currently > corrupting some people's DNS (presumably these are the NXDOMAIN > redirectors, or perhaps OpenDNS), will stop doing so if you deploy > DNSSEC to authoritative resolvers and recursor. It won't work that > way. > >>> Not a big deal, IMHO, the increased channel security is worth it, but >>> it is something to keep in mind. >> it is a VERY BIG deal. am i the only one here to groks the size of the >> installed base? changes we make to the hop-by-hop are amplified by the >> number of endpoints. channeling bob halley: "ok, it works in the lab, >> now multiply all your numbers by six million." except here it's 600 >> million. > > You keep saying that but you don't have the numbers. You claimed > DNS-0x20 was trouble free yet it turned out that very important > domains (like google.com) failed for DNS-0x20 users. > > "To measure is to know", and I do in fact have the EDNS-PING numbers. > The results are a very limited number of extra queries, and these are > 100.00% aimed at those few servers which reject EDNS-PING carrying > queries instead of ignoring them. This includes none of the important > nameserver implementations, and appears to be limited to some load > balancers. > > These would indeed suffer 1 extra query per hour or so do determine if > their support for EDNS(-PING) has changed (upwardly). > Most of these servers also reject EDNS queries anyhow. > > So please stick to facts instead of this hand waving which does not > befit an engineer. > > Bert > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknxjdIACgkQkDLqNwOhpPhgLACcDP10NmkiQAjsADFWGuv5hUPc MIUAn2JeG5YSo307yTm3nrLcY4SSTsXf =AK8t -----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 Apr 24 03:24:48 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1873A68F4; Fri, 24 Apr 2009 03:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_LOW=-1, 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 nHfQgSPSOhEu; Fri, 24 Apr 2009 03:24:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 455403A68BB; Fri, 24 Apr 2009 03:24:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxIXW-0000lH-2Z for namedroppers-data0@psg.com; Fri, 24 Apr 2009 10:21:50 +0000 Received: from [88.198.34.164] (helo=mail.bofh.priv.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxIXI-0000kZ-IE for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 10:21:43 +0000 Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 4BBE055400E for ; Fri, 24 Apr 2009 12:21:34 +0200 (CEST) Message-ID: <49F192AC.4080707@nic.at> Date: Fri, 24 Apr 2009 12:21:32 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> In-Reply-To: <20090423214248.GB32543@vacation.karoshi.com.> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bmanning@vacation.karoshi.com wrote: > > so what do I do? carry around a full-blown DNS IMR/Validator with my own > set of keys. While I agree that this is the best way to get secure DNS to your box, I doubt that this approach is feasible for the general public. I'm wondering what DNSSEC deployment scenarios we really expect to happen over the next years, even if we presume that DNSSEC will take off. Maybe the folks from Sweden and Brazil want to chime in, but from what I heard, the vast majority of client-side DNSSEC validation is done by the resolvers of ISPs. Yes, early adopters and geeks will run their own validators (either client-side, or by running their own recursors), but the majority of users rely on their ISPs. Most likely, they don't even know that their ISP is doing DNSSEC validation. Do we expect that to change? I don't really think so. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // -- to unsubscribe send a message to namedroppers-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 Apr 24 03:53:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B463A6CEC; Fri, 24 Apr 2009 03:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.777 X-Spam-Level: X-Spam-Status: No, score=-4.777 tagged_above=-999 required=5 tests=[AWL=-0.282, 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 uMrm58O0RsP3; Fri, 24 Apr 2009 03:53:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B969A3A687D; Fri, 24 Apr 2009 03:53:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxJ0A-0003bm-8w for namedroppers-data0@psg.com; Fri, 24 Apr 2009 10:51:26 +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 1LxIzd-0003Xp-8a for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 10:51:11 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n3OAniBh006500; Fri, 24 Apr 2009 10:49:44 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n3OAni2V006499; Fri, 24 Apr 2009 10:49:44 GMT Date: Fri, 24 Apr 2009 10:49:44 +0000 From: bmanning@vacation.karoshi.com To: Otmar Lendl Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090424104944.GB6307@vacation.karoshi.com.> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <49F192AC.4080707@nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F192AC.4080707@nic.at> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Apr 24, 2009 at 12:21:32PM +0200, Otmar Lendl wrote: > bmanning@vacation.karoshi.com wrote: > > > > so what do I do? carry around a full-blown DNS IMR/Validator with my own > > set of keys. > > While I agree that this is the best way to get secure DNS to your box, I > doubt that this approach is feasible for the general public. > > the vast majority of client-side DNSSEC validation is done by the > resolvers of ISPs. [elided] > Do we expect that to change? I don't really think so. why yes we do think so. > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // -- to unsubscribe send a message to namedroppers-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 Apr 24 03:53:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC363A687D; Fri, 24 Apr 2009 03:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.779, 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 J7ktqRWI6gIA; Fri, 24 Apr 2009 03:53:12 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1FF953A67F1; Fri, 24 Apr 2009 03:53:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxIyN-0003Rk-PS for namedroppers-data0@psg.com; Fri, 24 Apr 2009 10:49:35 +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 1LxIyB-0003RB-Cw for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 10:49:29 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n3OAlGBh006462; Fri, 24 Apr 2009 10:47:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n3OAlGis006461; Fri, 24 Apr 2009 10:47:16 GMT Date: Fri, 24 Apr 2009 10:47:16 +0000 From: bmanning@vacation.karoshi.com To: Paul Vixie Cc: Aki Tuomi , namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090424104716.GA6307@vacation.karoshi.com.> References: <26249.1240510804@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> <44750.1240535016@nsa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44750.1240535016@nsa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I'm not persuaded that we need the IAB to "declare victory and move on". There is a defined process to move protocol work to full standard and while that happens, I do not think it reasonable or practical to declare a moratorium on new ideas, proof of concept work, or technological advances. I'm pretty sure I want to see the ideas that folks have brought forward, discussed, documented, and tried out. Thats my impression of what the IETF should be doing... for -ALL- the ideas, not just the ones that happen to fit some current thinking on what is marketable, commercial, or even deployable on an interplanetary scale. What I am seeing is an over-agressive winnowing of ideas on how things might be done better/differently in favor of some fairly narrowly focused - "we have to have this stamped with the IETF imprinture so we can sell it" protocols. Please do not attempt to stiffle inovation just so the operational community can catch up to the protocols that are already defined. If the defined protocols are good enough, have intrinsic value, they will be adopted and can move along the standards track to full IETF standards. If they are not, then we really ought to allow alternatives to emerge and take their place. If the 15+years of DNSSEC development turns out to be non-operationally maintainable (again)... then i'm willing to consider cutting my losses and moving on to a more realistic, attainable goal... or find other ways to deploy naming integrity and authenticity in a more grass-roots fashion than the rather cumbersome choices that we currently face w/ DNSSEC deployment (and no, a signed root, or widescale adoption of DLV is not the paneca that one might think) So - I'm not in favor of the IAB making any sort of pronouncement about DNSSEC, other than to move it along the IETF standards track. --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 Fri Apr 24 04:04:30 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6273A6AA2; Fri, 24 Apr 2009 04:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_LOW=-1, 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 MovGur5-qrA3; Fri, 24 Apr 2009 04:04:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 387933A687D; Fri, 24 Apr 2009 04:04:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxJAB-0004no-Tr for namedroppers-data0@psg.com; Fri, 24 Apr 2009 11:01:47 +0000 Received: from [88.198.34.164] (helo=mail.bofh.priv.at) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxJ9x-0004m9-W7 for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 11:01:40 +0000 Received: from [10.10.0.211] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id 19B7355400E; Fri, 24 Apr 2009 13:01:32 +0200 (CEST) Message-ID: <49F19C0A.2070000@nic.at> Date: Fri, 24 Apr 2009 13:01:30 +0200 From: Otmar Lendl User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Antoin Verschuren CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> <3efd34cc0904230840l18c96a35lba7e67adfd540b6d@mail.gmail.com> <850A39016FA57A4887C0AA3C8085F949C4F2CD@KAEVS1.SIDN.local> In-Reply-To: <850A39016FA57A4887C0AA3C8085F949C4F2CD@KAEVS1.SIDN.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Antoin Verschuren wrote: > > So my first question would be, is it the intention to turn EDNS0 ping OFF > once we have deployed DNSSEC so we can reduce the complexity > and traffic again ? It's the client's decision to include EDNS0 ping in a query. I could imagine that a validating client chooses not to include that option when he knows that he's dealing with a DNSSEC-signed zone. Remember: the hard part is on the client side. The server part is trivial. > > And speaking of traffic, yes that's my greatest worry too. The additional bytes in the request don't bother me. If you want to increase the size of the Query-ID, then it should be no surprise that you need to send a few more bytes over the wire. No, the only worry I have in that respect are the repeated queries caused by probing / fallback (and thus duplicate requests). Now, what amount of fallback queries is due to the fact that the server side doesn't support EDNS0 at all? (versus no support for EDNS0 PING)? We already see live out there in the normal traffic EDNS0 enabled queries which need to be resent as the server side doesn't support EDNS0. So whatever retransmits the EDNS0 PING requests generate need to be compared to this base level of EDNS0 probing/fallback. Whatever we do with EDNS0-PING, we should strive to get draft-ietf-dnsext-rfc2671bis-edns0 done. If we get that published and implemented, then the additional retransmits due to the EDNS0-Ping should go to zero. Regardless of whether the the server supports EDNS0-ping or not. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // -- to unsubscribe send a message to namedroppers-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 Apr 24 04:10:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8060F3A6FFA; Fri, 24 Apr 2009 04:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-0.362, 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 kqCNQPXRGsmg; Fri, 24 Apr 2009 04:10:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 890B43A6FF7; Fri, 24 Apr 2009 04:10:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxJFh-0005eb-2Y for namedroppers-data0@psg.com; Fri, 24 Apr 2009 11:07:29 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxJFS-0005bb-6D for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 11:07:20 +0000 Received: by ewy2 with SMTP id 2so954484ewy.41 for ; Fri, 24 Apr 2009 04:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=omM442y4FaIREar31vnaHTYJBFeaYNZUP+bk9puSdTA=; b=lDkqeYuF68Ort2F3pCMoPxscd8bXJJM86wa/vzAbdVNXzmCt9bHBn+JkTLITPxePlm O2oi4XOMASiTC37DjbRfhGmlpabC7wJiNhwNeBVQpgRhZuzcbHMn34UN1fMzt03FPrEO eiz8VX346tOKDkkEMATSylgLs/LtXCoyzpScE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SRIb7Wo9FfOZxRaEK2mIZXwbRMUCgjkzGxZ0mk9HTGP44z56He2SSP0sOY2JDGS4ol AYcfrJJllmi8u11BHbnHq/6rcxw4LMwxCW5fOOG9QEPZ5HKv6jLZWKA91HJ3sKheKJDm z028vKfzaBjudjaSpUNctJeOn6tK9UPCQ1HWc= MIME-Version: 1.0 Received: by 10.210.89.4 with SMTP id m4mr2179037ebb.17.1240571231228; Fri, 24 Apr 2009 04:07:11 -0700 (PDT) In-Reply-To: <49F03A6E.8080504@nlnetlabs.nl> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <49F03A6E.8080504@nlnetlabs.nl> From: bert hubert Date: Fri, 24 Apr 2009 13:06:56 +0200 Message-ID: <3efd34cc0904240406w6c9f0e5bvd3fcf1eebf2e7c77@mail.gmail.com> Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? To: "W.C.A. Wijngaards" Cc: namedroppers@ops.ietf.org, Stephane Bortzmeyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 11:52 AM, W.C.A. Wijngaards w= rote: > Looking at this proposal as an implementor, I have to have answers from > the working group to questions (below) if this draft is standards-track. > =A0If the working group can answer them (in this draft or in others), the= n > the EDNS0 PING approach could be worth it, and then I support the group > working on EDNS0 PING. Wouter, The explicit goal of EDNS-PING is not to regulate too much, and only provide a framework which can be used to achieve certain goals. It is however important to point out how the framework *could* be used to achieve these goals. One goal is to make 'blind spoofing' or even 'triggered blind spoofing' highly unlikely to succeed. > *[Probe] =A0How do you probe for support of the EDNS0 PING option? =A0Tel= l > me about error returns, dropped messages, option ignored, option > disables EDNS0 (but not further query) processing, timeouts... Protection extends only towards communications between implementations that support EDNS0 PING. Any authoritative server that includes this option does its bit. This means that an originator of queries needs: 1) a solid way to determine EDNS-PING support, and 2) make sure that the knowledge of this support can't conceivably be downgr= aded. Both items are not too hard to achieve - it is trivial to probe for EDNS-PING support, and it is very hard for an attacker to influence such a probe: it has only 1 chance to do so. Once the level of support is known, store this knowledge for a random period of time. Once the status expires, head back to '1'. Do not believe any answers from this host that are not EDNS-PING adorned. If you want to delve into details, I am more than happy to share the various ideas being discussed to make the above highly robust. > *[Fallback] =A0How do you fallback? =A0When the probe is not successful, = how > do you fallback in a secure, non-antisocial manner. You don't - without EDNS-PING, there is no EDNS-PING. Urge the DNSSEC community to get stuff deployed and out on the clients. > *[Interop] =A0What fallback method(s) should be implemented? =A0If a > resolvercluster is using different fallback implementations, they can > get different answers, and thus start giving different answers to the > same query. =A0Interoperability problems between resolvers. Outside of the scope of the draft. > *[Downgrade] =A0Is the group convinced that there is no downgrade attack? Olafur invented (or, re-discovered) an interesting way to probe for support securely. When talking to a remote about domain 'example.com', send it a query for 'sdfkjhsdfkjshdfkshdfkjh.example.com' as a probe to see if it support EDNS-PING, where 'ssdfsfsfsdfsdfsdfsdkjh' is of course random. This serves as a long additional keyspace that an attacker would have to guess in order to spoof in a reply that indicates no EDNS-PING support. I'm not even sure if this clever idea is necessary though - it does provide an additional layer of safety though. > *[State] =A0The result of the probe, how to keep it around? =A0What is th= e > TTL of that state? =A0When do you re-probe? =A0Is the resolver fully > vulnerably when starting up? =A0What is the cache policy for the state, > i.e. when cache memory is full and new probes are done, what domains are > made insecure? Up to implementors. One of the things that is important to realise is that this draft should not be measured by the same stick as DNSSEC - its goals are more modest, and much more of the use of EDNS-PING is up to the resolver implementors. Bert -- to unsubscribe send a message to namedroppers-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 Apr 24 04:22:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2888528C131; Fri, 24 Apr 2009 04:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.595 X-Spam-Level: ** X-Spam-Status: No, score=2.595 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 b3xtM-MheS25; Fri, 24 Apr 2009 04:22:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C476828C6A8; Fri, 24 Apr 2009 04:22:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxJRV-0007My-Lo for namedroppers-data0@psg.com; Fri, 24 Apr 2009 11:19:41 +0000 Received: from [195.188.213.6] (helo=smtp-out3.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxJRJ-0007LK-DH for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 11:19:35 +0000 Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1LxJRF-0006LK-4c; Fri, 24 Apr 2009 12:19:25 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out3.blueyonder.co.uk with esmtpa (Exim 4.52) id 1LxJRE-0002Ev-Hj; Fri, 24 Apr 2009 12:19:24 +0100 Message-ID: From: "George Barwood" To: "W.C.A. Wijngaards" , "bert hubert" Cc: References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <17616.1240499031@nsa.vix.com> <3efd34cc0904230840l18c96a35lba7e67adfd540b6d@mail.gmail.com> <49F18DD3.5010508@nlnetlabs.nl> Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Fri, 24 Apr 2009 12:19:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "W.C.A. Wijngaards" To: "bert hubert" Cc: Sent: Friday, April 24, 2009 11:00 AM Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have asked questions too, and without answers on those topics, I do > not think this draft can become a working group document. The reason > those answers are needed is that the issues are important for security > and interoperability. > > You note F5 interoperability concerns, and I think there may be > interoperability issues using loadbalancers and different fallbacks. > Going from the lab to the DNS world, there are surely many more. > > I believe that EDNS PING as specified in the current version of the > draft is _not_ secure. Without documentation we cannot tell how to make > it secure, and thoughts by me and others (expressed on this list, some > as answers to my questions) are that EDNS PING suffers from severe > downgrade problems. For a working group draft EDNS PING has to be > convincingly an addition to security. EDNS PING is not in itself secure or insecure. As explained by Nicholas Weaver, it is possible to build a secure resolver using EDNS PING by falling back on query repetition. You might say, if there is a secure fallback, why do we need EDNS PING at all? The answer is efficiency - query repetition can be quite expensive for non-deterministic authorities (in some cases my resolver use 10 queries instead of one, even when glue is discarded), with some performance trade-offs (as explained in my draft), so defining an efficient way of securely communicating with these servers is sensible. In the longer term, once deployment of EDNS Ping is near universal, a reasonable fallback will be to report failure (or possibly a warning), which is a much simpler solution. > Also I see deployment trouble, your words seem to indicate that you > retry non-EDNS-PING server probes every hour, but EDNS-PING capable > servers stay that way forever. This means that once deployed, a site > can never ever change their server software or turn it off (once they > have other security in place, DNScurve or DNSSEC)? Although I agree > with Andreas that overspecification is bad, text is needed to advise > implementors here. That would be an erroneous implementation. > Based on the arguments above I believe that EDNS PING, as specified now, > is (highly) experimental and not ready for standards track. In fact, as > an implementor I will not implement the specification in the default > configuration if the fallback mechanisms are not properly described, I > believe that those lead to interoperability issues. Once the EDNS Ping specification is on the standards track, there will be plenty of time to research the best ways to use it on the client side. Clearly there will need to be plenty of testing performed before client side deployment can take place. However, it can be deployed server side quite early. [snip] -- to unsubscribe send a message to namedroppers-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 Apr 24 05:08:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BE828C19E; Fri, 24 Apr 2009 05:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=-0.662, 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 P4rZ7x-SoCdm; Fri, 24 Apr 2009 05:08:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64BB03A6E64; Fri, 24 Apr 2009 05:08:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxK94-000Dbr-N6 for namedroppers-data0@psg.com; Fri, 24 Apr 2009 12:04:42 +0000 Received: from [68.142.224.75] (helo=smtp120.rog.mail.re2.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxK8i-000DYt-UJ for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 12:04:36 +0000 Received: (qmail 76083 invoked from network); 24 Apr 2009 12:04:17 -0000 Received: from unknown (HELO connotech.com) (thierry.moreau@209.148.165.15 with plain) by smtp120.rog.mail.re2.yahoo.com with SMTP; 24 Apr 2009 12:04:17 -0000 X-YMail-OSG: 80sWl3oVM1lQ0YpFwthLdFQVxcVuobPT3EZGhuDBmPpl8TIp_HRiQdsfpCB8aDEJ_Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F1A9EC.1040800@connotech.com> Date: Fri, 24 Apr 2009 07:00:44 -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: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS References: <26249.1240510804@nsa.vix.com> In-Reply-To: <26249.1240510804@nsa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear all: I guess the important portion from the Paul's post below is "I'd like the IAB to weigh in on the question: 'Is Secure DNS complete?'" Otherwise, Paul wrote a DNSSEC deployment promotion message. I have a few issues with the way Paul addresses the community. See inline below. Paul Vixie wrote: > Chairs, please invoke some kind of review process by the IAB so that we can > get some direction on Secure DNS. We've got TSIG and TKEY and GSS TSIG and > SIG(0), and we've got DNSSEC, and we've got SPR. To me that's enough, it's > a complete system supporting both end to end (DNSSEC) and hop by hop (SPR, > TSIG, or or TKEY+SIG(0)) security. However, the engineering mindset that > dominates this working group is now way into its customary overshoot > (DNS-0x20, EDNS PING, cookies) and there is at least one major > non-working-group project (dnscurve) in the works. So far, not so bad. Using proper English capitalization is good salesmanship! But perhaps this delves too much into technical details. Indeed, this paragraph triggered further technical discussions. A basic rule of salesmanship is to avoid creating doubt and/or confusion. > The effect of this overshoot is to dilute interest in existing Secure DNS > technologies. Fence sitters can say "well clearly the wheels are still > turning, let's see how it shakes out before we make any investment." This > fulfills the prophecy of these overshooters ("DNSSEC is too hard to deploy, > so clearly we need to continue investigating other solutions.") What the > Secure DNS effort needs is some nontechnical governance. I'd like the IAB > to weigh in on the question: "Is Secure DNS complete?" so that the working > group can know a priori and on nontechnical grounds whether to continue > accepting new work items in this area. > (Note that I have personally quashed three mindblowingly better solutions > to things that DNSSEC got wrong, because at some point you have to cut and > print.) I will neither ask what are these "better solutions" nor question whether "things that DNSSEC got wrong" are actually detrimental to the overall scheme. From the above statement, I become puzzled about the confidence that IETF outsiders may lose in the IETF processes that brought the DNSSEC specifications. I mean a) the IETF process is collective engineering based on consensus, b) Paul, a well-known DNS expert, claims *personal* attribution of three unspecified "things that DNSSEC got wrong," c) perhaps the IETF process that led to the DNSSEC specifications was overwhelmingly influenced by Paul. Philosophically, DNSSEC being a security solution, there is a "security assurance requirement" (à la Common Criteria), according to which a secure system design must not only be sound, it must have been designed by a process about which soundness assertions must be validated. I hope Paul, if asked by someone more influential than merely myself, can bring pointers to a significant IETF consensus in each of the three alluded instances alluded above, so the lack of confidence in the soundness of IETF process does not turn into lack of "security assurance" in the DNSSEC solution. So, some integrity confidence in the IETF process can be salvaged despite the above statement. > (Also note that I've been working on Secure DNS for close to 15 > years now, and the apparent endlessness of it is starting to get on my > nerves, and is NOT a simple artifact of protocol quality, which is why I'm > indicting the engineering mindset prevalant in the DNSEXT working group.) As I understand it, DNSSEC engineering is essentially done, other elements of Secure DNS don't require the same level of deployment coordination as required by DNSSEC, and hence the endlessness of its starting now lies outside of the IETF and the IAB. And I doubt DNSEXT working group volunteers are indebted towards Paul to the point where they should abstain from bringing forward new ideas. They don't *have to* keep quiet while Paul's ideas are being adopted. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.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 Apr 24 05:16:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0787A3A7015; Fri, 24 Apr 2009 05:16:13 -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 cnITARlmcnFO; Fri, 24 Apr 2009 05:16:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 506753A7008; Fri, 24 Apr 2009 05:16:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxKI5-000Eq3-F1 for namedroppers-data0@psg.com; Fri, 24 Apr 2009 12:14:01 +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 1LxKHp-000EoR-8y for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 12:13:54 +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.3/8.14.3) with ESMTP id n3OCDeVJ086987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2009 14:13:41 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <49F1ACF4.7020901@nlnetlabs.nl> Date: Fri, 24 Apr 2009 14:13:40 +0200 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: bert hubert CC: namedroppers@ops.ietf.org, Stephane Bortzmeyer Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <49F03A6E.8080504@nlnetlabs.nl> <3efd34cc0904240406w6c9f0e5bvd3fcf1eebf2e7c77@mail.gmail.com> In-Reply-To: <3efd34cc0904240406w6c9f0e5bvd3fcf1eebf2e7c77@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 24 Apr 2009 14:13:41 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bert, Thank you for answering. It would be great to have some of this taken up in the draft (if adopted). To document some way to make it work securely. So I would like you to pick up (some of) your (or mine) stuff below and mention it in the draft. bert hubert wrote: > The explicit goal of EDNS-PING is not to regulate too much, and only > provide a framework which can be used to achieve certain goals. No problem here. > It is however important to point out how the framework *could* be used > to achieve these goals. This is exactly what I was trying to point out. > One goal is to make 'blind spoofing' or even 'triggered blind > spoofing' highly unlikely to succeed. Obvious, yes. >> *[Probe] How do you probe for support of the EDNS0 PING option? > > This means that an originator of queries needs: > 1) a solid way to determine EDNS-PING support, and > 2) make sure that the knowledge of this support can't conceivably be downgraded. > > Both items are not too hard to achieve - it is trivial to probe for > EDNS-PING support, and it is very hard for an attacker to influence > such a probe: it has only 1 chance to do so. > Once the level of support is known, store this knowledge for a random > period of time. Once the status expires, head back to '1'. Do not > believe any answers from this host that are not EDNS-PING adorned. This looks good. It would be good to note the probe simplicity proposed. Also the expire of state. And ignoring bad PING replies (to remind the silly programmers). > If you want to delve into details, I am more than happy to share the > various ideas being discussed to make the above highly robust. >> *[Fallback] How do you fallback? When the probe is not successful, how >> do you fallback in a secure, non-antisocial manner. > > You don't - without EDNS-PING, there is no EDNS-PING. Urge the DNSSEC > community to get stuff deployed and out on the clients. So this is food for downgrade worries. To protect against you need to protect the probe. Perhaps you should emphasize the random timeout on the state a bit more. And Olafur's idea below. Another problem to examine is startup, when the time of probes is known, again to protect that probe. For example, disrupting communications while probing is done (no replies received by prober) would create a downgrade. >> *[Interop] What fallback method(s) should be implemented? > Outside of the scope of the draft. You already stated 'fallback to non-EDNS PING query' above. I want this topic to be in the draft. >> *[Downgrade] Is the group convinced that there is no downgrade attack? > > Olafur invented (or, re-discovered) an interesting way to probe for > support securely. When talking to a remote about domain 'example.com', > send it a query for 'sdfkjhsdfkjshdfkshdfkjh.example.com' as a probe > to see if it support EDNS-PING, where 'ssdfsfsfsdfsdfsdfsdkjh' is of > course random. This serves as a long additional keyspace that an > attacker would have to guess in order to spoof in a reply that > indicates no EDNS-PING support. > > I'm not even sure if this clever idea is necessary though - it does > provide an additional layer of safety though. A very nice idea, proposing something like this has a good place in the draft. I note it shouldn't be too long, so that DNAME'd zones do not run into YXDOMAIN errors on the probe. If you get YXDOMAIN errors, try multiple shorter-named probes (perhaps). So a positive reply is usually very strong, with the PING in there and maybe a long name. So in that case good security gets provided (what I previously referred to as 'only in good weather'). A negative reply, if it does not contain a long random query name, is not so very secure. I think the draft SHOULD recommend that the random timeout be much lower in that case, for example, or something better. (i.e. negative reply by timeout, by error without qname, ...). It is these replies that are most downgrade sensitive, turning EDNS PING into 'but you have to spoof twice in a row'. I think they need to be handled with care. A negative reply with the long random query name (thank you Olafur!), is very good. It provides some higher level of confidence that this negative "just don't use EDNS PING now, OK?" reply is not a spoof but from the original source. I note this extended-qname probe query is an extra query that is done. To make sure not too many probes are sent, the values of the (random) timeouts should also be documented, does not have to be MUST, but SHOULD is OK. Documenting may not be fun, but you really have to do it. Perhaps analysis of which servers are expected to get how many probes, and how many probes a real world resolver sends ... For domains that usually only every get one query per resolver, the probe can be expected to double the load. While for say .com servers, the increase is smaller. This is a little like the cookies draft we had some time ago [eastlake]. >> *[State] The result of the probe, how to keep it around? > Up to implementors. The important bit you said above was that it expires. This sort of stuff really needs to be in the draft. > One of the things that is important to realise is that this draft > should not be measured by the same stick as DNSSEC - its goals are > more modest, and much more of the use of EDNS-PING is up to the > resolver implementors. Well, the idea is to add safety. As it stands, bad choices can make for very bad security. And if you document the above, the expected security from the EDNS PING option could improve considerably. By protecting the probe, making it timeout properly, and randomising the time it is sent, the draft becomes much stronger in its security. I think this really needs to be part of the draft. Again, thank you for addressing my concerns. I still think downgrade risk has to be analysed more thoroughly. However, I understand this is the first draft submission, and you intend to have it improved by the working group. So, with concerns (to be) documented in the draft, I have no problem with the working group working on this draft. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAknxrPQACgkQkDLqNwOhpPjlFwCfXY1rgH0yrE3381t5Xo5kwIsK x+QAoJPb+U2o/+gvHYXyVFY36w4vGBte =t1qS -----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 Apr 24 05:47:06 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E1C3A7385; Fri, 24 Apr 2009 05:47: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 btdb27FtwVQD; Fri, 24 Apr 2009 05:47:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B89F23A6A02; Fri, 24 Apr 2009 05:47:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxKki-000IGv-Ff for namedroppers-data0@psg.com; Fri, 24 Apr 2009 12:43:36 +0000 Received: from [2001:748:301::2] (helo=shinjuku.zaphods.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxKkT-000IEa-Ae for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 12:43:29 +0000 Received: from zaphodb by shinjuku.zaphods.net with local (Exim 4.69) (envelope-from ) id 1LxKkS-0004Bd-J7 for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 14:43:20 +0200 Date: Fri, 24 Apr 2009 14:43:20 +0200 From: Stefan Schmidt To: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090424124320.GF870@zaphods.net> References: <26249.1240510804@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> <44750.1240535016@nsa.vix.com> <20090424104716.GA6307@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090424104716.GA6307@vacation.karoshi.com.> X-Origin-AS: AS5430 X-NCC-nic-hdl: ZAP-RIPE User-Agent: Mutt/1.5.18 (2008-05-17) X-bounce-key: BOUNCE_ID;zaphodb@zaphods.net;1240577002;2f78d63e; Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Apr 24, 2009 at 10:47:16AM +0000, bmanning@vacation.karoshi.com wrote: > > I'm not persuaded that we need the IAB to "declare victory and move on". > There is a defined process to move protocol work to full standard and while > that happens, I do not think it reasonable or practical to declare a > moratorium on new ideas, proof of concept work, or technological advances. > ... I would have written about the same but probably with a worse choice of words, so thank you Bill for beeing faster. > So - I'm not in favor of the IAB making any sort of pronouncement about DNSSEC, other > than to move it along the IETF standards track. I concur with everything Bill wrote in his previous mail, so all there is left for me to say now on this issue is: Me too. Stefan -- "And how would we hide a 30,000-ton submarine?" "You hide a submarine by sinking it," Painter said angrily. "They're designed to do that, you know." - Ryan and Adm. Painter, "The Hunt for Red October" (Tom Clancy) -- to unsubscribe send a message to namedroppers-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 Apr 24 05:48:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2A13A73B2; Fri, 24 Apr 2009 05:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 lpPzwpONJZtU; Fri, 24 Apr 2009 05:48:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2AC173A73AB; Fri, 24 Apr 2009 05:48:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxKms-000IUR-2i for namedroppers-data0@psg.com; Fri, 24 Apr 2009 12:45:50 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxKme-000ITd-KC for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 12:45:43 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3OCjK2x011390; Fri, 24 Apr 2009 05:45:20 -0700 (PDT) Cc: Nicholas Weaver , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org, Stephane Bortzmeyer Message-Id: From: Nicholas Weaver To: bert hubert In-Reply-To: <3efd34cc0904240406w6c9f0e5bvd3fcf1eebf2e7c77@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Fri, 24 Apr 2009 05:45:20 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <49F03A6E.8080504@nlnetlabs.nl> <3efd34cc0904240406w6c9f0e5bvd3fcf1eebf2e7c77@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 24, 2009, at 4:06 AM, bert hubert wrote: > On Thu, Apr 23, 2009 at 11:52 AM, W.C.A. Wijngaards > wrote: >> Looking at this proposal as an implementor, I have to have answers >> from >> the working group to questions (below) if this draft is standards- >> track. >> If the working group can answer them (in this draft or in others), >> then >> the EDNS0 PING approach could be worth it, and then I support the >> group >> working on EDNS0 PING. > > Wouter, > > The explicit goal of EDNS-PING is not to regulate too much, and only > provide a framework which can be used to achieve certain goals. > > It is however important to point out how the framework *could* be used > to achieve these goals. > > One goal is to make 'blind spoofing' or even 'triggered blind > spoofing' highly unlikely to succeed. The problem: EDNS0 ping is only good for two things: a) Adding entropy into requests and b) Acting as "stateless state", a way for a client to offload state holding onto the server. The latter is only useful with universal deployment, and the amount of state we are talking about is trivial. So it really is only good for A: increasing request entorpy. Thus saying "we don't want to regulate too much" and "its just a framework" does the proposal a disservice. EDNS0 ping is ONLY a mechanism for increasing query entropy. As such, I agree with Wouter: I think it is a mistake not to specify exactly how to use EDNS0 ping to protect traffic, and security related RFCs should be complete cookbook: IF you implement it in exactly this way, you achieve security goals X Y and Z. Other ways MAY work, but your mileage may vary. This is also why I think fallback behavior when EDNS0 ping is not responded to should be explicitly in the specification, as it is for 0x20, because this allows surveys and expectations on how things can evolve, what load EDNS0 ping partial deployment will cause, etc etc etc. The goal should be "If only SOME systems support EDNS0 ping, those resolvers using it should benefit REGARDLESS of the behavior of individual authorities". Otherwise, as a double sided change, it has deployment headaches not present in say, 0x20 (which is a pseudo- single-sided change). -- to unsubscribe send a message to namedroppers-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 Apr 24 05:59:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D383A73BC; Fri, 24 Apr 2009 05:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 qWGUL+o41pNO; Fri, 24 Apr 2009 05:59:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 755023A6A43; Fri, 24 Apr 2009 05:59:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxKxH-000Jnh-49 for namedroppers-data0@psg.com; Fri, 24 Apr 2009 12:56:35 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxKww-000JkN-3w for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 12:56:25 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3OCu6Kf012701; Fri, 24 Apr 2009 05:56:06 -0700 (PDT) Cc: Nicholas Weaver , namedroppers@ops.ietf.org Message-Id: <2CEF9F64-FE88-4289-AB28-4A986B8E1B7D@icsi.berkeley.edu> From: Nicholas Weaver To: Otmar Lendl In-Reply-To: <49F192AC.4080707@nic.at> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Fri, 24 Apr 2009 05:56:06 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <49F192AC.4080707@nic.at> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 24, 2009, at 3:21 AM, Otmar Lendl wrote: > bmanning@vacation.karoshi.com wrote: >> >> so what do I do? carry around a full-blown DNS IMR/Validator with >> my own >> set of keys. > > While I agree that this is the best way to get secure DNS to your > box, I > doubt that this approach is feasible for the general public. > > I'm wondering what DNSSEC deployment scenarios we really expect to > happen > over the next years, even if we presume that DNSSEC will take off. Actually, this is the most feasible approach as well, in my opinion... Here's how. The US government signs .gov and .mil, and all within it, and leans on the roots to finally sign something, so you have a path from root -> (.gov, .mil, sweeded, brazil, etc..) And then leans on Microsoft to have the stub resolver in Windows whatever validate based on the signed root, by using its market power. or Verisign makes it a condition of EV certs that the browser also verify the address using DNSSEC (of course, this adds no real security, but hey, EV certs are stupid to begin with, "Pay us more to do the job we should have done right in the first place..." etc. If the recursive resolvers a) Are the only one checking DNSSEC and b) Still accept unsigned data fine, authorities have almost no incentive to upgrade. But if the user's computers are a) Checking DNSSEC and b) Complaining when its absent Now authorities are forced to deplay. -- to unsubscribe send a message to namedroppers-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 Apr 24 06:12:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B463A7016; Fri, 24 Apr 2009 06:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 QWCJwufy8ZBG; Fri, 24 Apr 2009 06:12:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3EB328C1E8; Fri, 24 Apr 2009 06:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxL8B-000L41-Qi for namedroppers-data0@psg.com; Fri, 24 Apr 2009 13:07:51 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxL7x-000L2U-P3 for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 13:07:45 +0000 Received: (qmail 87853 invoked from network); 24 Apr 2009 14:22:11 -0000 Received: from bmdk2178.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (203.180.16.178) by necom830.hpcl.titech.ac.jp with SMTP; 24 Apr 2009 14:22:11 -0000 Message-ID: <49F1B865.6000900@necom830.hpcl.titech.ac.jp> Date: Fri, 24 Apr 2009 22:02:29 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Paul Vixie , Aki Tuomi , namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS References: <26249.1240510804@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> <44750.1240535016@nsa.vix.com> <20090424104716.GA6307@vacation.karoshi.com.> In-Reply-To: <20090424104716.GA6307@vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: bmanning@vacation.karoshi.com wrote: > I'm not persuaded that we need the IAB to "declare victory and move on". > There is a defined process to move protocol work to full standard The problem is not on moving on but on not moving on. There is no way to delcare some protocol hopeless in IETF as long as some people are actively support the protocol in related WGs. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 24 06:42:07 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2483A6BAE; Fri, 24 Apr 2009 06:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.496 X-Spam-Level: ** X-Spam-Status: No, score=2.496 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, 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 aVnIMuD3IoTb; Fri, 24 Apr 2009 06:42:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A1973A6B8A; Fri, 24 Apr 2009 06:40:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxLbD-000PCE-0q for namedroppers-data0@psg.com; Fri, 24 Apr 2009 13:37:51 +0000 Received: from [195.188.213.8] (helo=smtp-out5.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxLav-000PB8-Q0 for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 13:37:40 +0000 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1LxLan-0001jy-HE; Fri, 24 Apr 2009 14:37:25 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with esmtpa (Exim 4.52) id 1LxLam-0004rZ-Bo; Fri, 24 Apr 2009 14:37:24 +0100 Message-ID: <083E465E83964BD384AD95D4C27DF679@localhost> From: "George Barwood" To: "Nicholas Weaver" , "bert hubert" Cc: "W.C.A. Wijngaards" , , "Stephane Bortzmeyer" References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <20090423083149.GA17599@nic.fr> <49F03A6E.8080504@nlnetlabs.nl> <3efd34cc0904240406w6c9f0e5bvd3fcf1eebf2e7c77@mail.gmail.com> Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Fri, 24 Apr 2009 14:37:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Nicholas Weaver" To: "bert hubert" Cc: "Nicholas Weaver" ; "W.C.A. Wijngaards" ; ; "Stephane Bortzmeyer" Sent: Friday, April 24, 2009 1:45 PM Subject: Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? [snip] > The goal should be "If only SOME systems support EDNS0 ping, those > resolvers using it should benefit REGARDLESS of the behavior of > individual authorities". Otherwise, as a double sided change, it has > deployment headaches not present in say, 0x20 (which is a pseudo- > single-sided change). This goal is achievable. An authority that implements EDNS0 ping achieves improved security with clients that probe. That's because a blind attacker will need to spoof (or DOS) the probe AND spoof the subsequent unprotected query. That's nice, because it gives a good motive for both authorities and clients to deploy. Even if the client adopts a simple probe approach. Such clients will still be vulnerable to spoofing when querying non-upgraded servers, which is why I would advocate duplication / repetition. But simpler strategies still achieve improved security, and give a different incentive for authorities to upgrade ( security versus load ). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 24 07:04:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E2B28C248; Fri, 24 Apr 2009 07:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.954, 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 iqf77xStY3t6; Fri, 24 Apr 2009 07:04:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B36728C1E4; Fri, 24 Apr 2009 07:04:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxLwS-0002a0-Su for namedroppers-data0@psg.com; Fri, 24 Apr 2009 13:59:48 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxLwE-0002YM-JB for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 13:59:41 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3ODxSYc036047; Fri, 24 Apr 2009 09:59:29 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904241359.n3ODxSYc036047@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 24 Apr 2009 09:58:59 -0400 To: IESG Secretary From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair Subject: [dnsext] Document Advancement: draft-ietf-dnsext-dnsproxy-05.txt Cc: dnsext-ads@tools.ietf.org, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ralph, Here is the first document from DNSEXT you get to bring to the IESG. This is a non controversial document, that we hope will sail through. Please start an IETF LC as soon as feasible. Document: draft-ietf-dnsext-dnsproxy-05.txt Statement: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Olafur Gudmundsson DNSEXT co-chair. This version has addressed all issues raised in the working group last call and the document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes it has. No concerns about quality of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There is no community within the IETF that this document needs more review from. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No issues. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Real strong (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Yes, I have checked the document. There is one issues flagged by ID-nits: == There are 1 instance of lines with non-RFC3330-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. I think this is referring to the following text: 231 Should a UDP query fail because of truncation, the standard fail-over 232 mechanism is to retry the query using TCP, as described in section 233 6.1.3.2 of [RFC1123]. In this case the tool can not tell the difference between a section number in RFC1123 and an IPv4 address! (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes references are split. There are no downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document does not require any IANA actions. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Does not apply. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document is aimed at a target audience that is outside the IETF but implement DNS protocol elements, frequently without much understanding of the DNS protocol. This document gives simple guidance to such people to avoid common mistakes, seen in the field, that cause major interoperabilty issues. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The consensus for this document is real strong. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? This is a high quality draft, that is addressing an important aspect for the interoperabilty of the DNS protocol. Number of vendors that purchase/test DNS gateways have stated that compliance with this document is going to be a purchasing requirement. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document Shepherd is: Olafur Gudmundsson AD: Ralph Droms Olafur and 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 Apr 24 08:18:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EC63A6BFA; Fri, 24 Apr 2009 08:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_51=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 PjOa5ezcwPC5; Fri, 24 Apr 2009 08:18:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EB8828C1A3; Fri, 24 Apr 2009 08:18:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxN6h-000Bhw-65 for namedroppers-data0@psg.com; Fri, 24 Apr 2009 15:14:27 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxN6U-000BfG-HP for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 15:14:20 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 453582FE960A for ; Fri, 24 Apr 2009 15:14:11 +0000 (UTC) Date: Fri, 24 Apr 2009 11:14:09 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090424151409.GF70585@shinkuro.com> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090423214248.GB32543@vacation.karoshi.com.> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Co-chair hat on. On Thu, Apr 23, 2009 at 09:42:48PM +0000, bmanning@vacation.karoshi.com wrote: > the only ISP i trust implicitly is the one servicing my house.. > so what do I do? carry around a full-blown DNS IMR/Validator with my own > set of keys. Yes, I'll end up getting an IP address from your handy > DHCP/RA server (and apparently a bunch'o'worthless crap that I'll either > dump or quarentine) ... And I'll happily build an IPSEC tunnel back to > a trusted environment and go from there if you try and box me in. (Thanks > Sam for pointing out how to run IP over DNS and Steve for how to run IP over > HTTP) None of the above argument (and I'm including others' posts in the thread, too -- this is just a handy paragraph on which to hang the remark) suggests even a little bit in the way of protocol work. On the contrary, this sounds very much like, "The protocol is done, and we really need to get the integration and operations parts polished, ready, and easy to use." It's easy for Bill to do the above, but the average laptop user would stop for sure at "IMR/Validator with my own set of keys" and maybe at "DNS". Perhaps we need howtos, operations documents, BCP or Informational documents or such -- but this is all deployment and coding, not new protocol. That sounds to me like a very strong argument for _not_ doing any more forgery resilience or other such work, and for this WG to stop fiddling with the security parts of the protocol: it sounds like we need to stop distracting people who could be working on polishing the deployment tools with shiny new protocol knobs to turn. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 24 08:18:47 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8211D3A6BFA; Fri, 24 Apr 2009 08:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.348, 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 aUuFMZG1JywV; Fri, 24 Apr 2009 08:18:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DA603A6403; Fri, 24 Apr 2009 08:18:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxN8p-000BxE-NC for namedroppers-data0@psg.com; Fri, 24 Apr 2009 15:16:39 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxN8Z-000Bva-H9 for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 15:16:31 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id C854A3A6BFA; Fri, 24 Apr 2009 08:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-13.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090424151502.C854A3A6BFA@core3.amsl.com> Date: Fri, 24 Apr 2009 08:15:02 -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 : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Author(s) : J. Jansen Filename : draft-ietf-dnsext-dnssec-rsasha256-13.txt Pages : 10 Date : 2009-04-24 This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-rsasha256-13.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-dnssec-rsasha256-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-24080614.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 Fri Apr 24 08:54:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C87C3A69F0; Fri, 24 Apr 2009 08:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 zB7q8rejbkNT; Fri, 24 Apr 2009 08:54:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7EE6C3A6966; Fri, 24 Apr 2009 08:54:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxNgH-000GaZ-7E for namedroppers-data0@psg.com; Fri, 24 Apr 2009 15:51:13 +0000 Received: from [213.154.224.43] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxNen-000GKS-Al for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 15:49:47 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 282E5131489 for ; Fri, 24 Apr 2009 17:49:39 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id EE3FACFA0D for ; Fri, 24 Apr 2009 17:49:38 +0200 (CEST) Message-ID: <49F1DF92.2080709@NLnetLabs.nl> Date: Fri, 24 Apr 2009 17:49:38 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-13.txt References: <20090424151502.C854A3A6BFA@core3.amsl.com> In-Reply-To: <20090424151502.C854A3A6BFA@core3.amsl.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Internet-Drafts@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 : Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC I've replaced the NSEC3 text with the text proposed by Paul. I've also added a new section containing an example key and signature for both algorithms (the examples assume that algorithm identifiers 8 and 9 will be allocated). Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknx35IACgkQ4nZCKsdOncVNrQCgpbFm10w6ZchV42iWI0sxi2L3 W1AAnj0qGw1RAa0qUnhQYmXhKe0KiPoU =C7Fp -----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 Apr 24 09:28:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5413A6A01; Fri, 24 Apr 2009 09:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 RtEmSmbnUT0q; Fri, 24 Apr 2009 09:28:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 351653A6CE1; Fri, 24 Apr 2009 09:27:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxO8N-000L5J-FF for namedroppers-data0@psg.com; Fri, 24 Apr 2009 16:20:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxO81-000L2C-Uc for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 16:20:02 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 419C3A1064; Fri, 24 Apr 2009 16:19:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "Aki Tuomi" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS In-Reply-To: Your message of "Fri, 24 Apr 2009 08:51:04 +0300." <86048CA3B4B17E459FFD4F3F383AD88F13F27B5B@fi-hel2ex01.nordiclan.net> References: <26249.1240510804@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> <44750.1240535016@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B5B@fi-hel2ex01.nordiclan.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Fri, 24 Apr 2009 16:19:48 +0000 Message-ID: <89700.1240589988@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Fri, 24 Apr 2009 08:51:04 +0300 > From: "Aki Tuomi" > > First of all, I agree, let's find out. I am all for asking the chairs to > evaluate. The motivation behind my initial email was the perceived > attitude in your email as you blatantly stated that "DNNSEC good, others > bad". "having a plan is good, shooting into the dark is bad." if IETF wants to abandon DNSSEC and/or redefine the problem explicitly, i might hate the new plan but i'd be happy knowing that there was, at least, a plan. > This is indeed the message you sent by stating that the 0x20, EDNS PING, > DNSCurve etc. are "customary overshooting". It would be courteous to at > least acknowledge that these are serious attempts, and not just some > wishy washy engineering attempt that should be regarded as no more than > mere noise. As in, you could have extended a courtesy of acknowledging > that these are seriously considerable solutions. it was never my intent to hurt your feelings, and i'm sorry if i've done so. as the co-proponent of DNS-0x20 and the author of that Internet-Draft, i'm throwing myself down the same mineshaft: this working group is thrashing now. > But I agree. Some adult supervision seems to be necessary to calm down > both parties, but I just hope you'd show some courtesy and respect to the > other suggested solutions, instead of labeling them as noise. i can dial down the invective, and i will; thanks for your guidance on that. however, i want you (not just Aki but everyone) to consider that at some point IETF made a choice to develop what is now IPv6, and by doing so, they (we?) explicitly rejected more work on the competing alternatives. this was not done to conserve effort -- indeed, the people who wanted to work on the competing alternatives did by and large not "switch sides", they just gave up found a different topic to work in. rather, this was done in order to serve the community with a clear IPv4 migration message. good or bad, love it or hate it, we all know that the future is IPv6. we need a plan for Secure DNS, and we do have one: the plan of record is DNSSEC end to end, SPR hop by hop. if it's time to scrap that plan and start over then that's what IETF should do. if on the other hand it's time to focus on the missing pieces and only admit new work items to this WG that fill in such missing pieces (for example, defining a use profile for TKEY-over-TCP and either TSIG or SIG(0) for hop-by-hop, or adding DNS-0x20 or EDNS-PING to hop-by-hop) then that's what we should do. if on the other hand time has moved on and DNSCurve is the way we should go, then we should go that way and abandon everything else. my indictment of the engineering mindset yesterday (and continuing) is not that engineers are evil or incompetent by nature (recall that i wrote the I-D for DNS-0x20) but rather than the engineering mindset, running rampant, is not a good way to get a product completed and out the door and into customer hands. "put all the boats in the water and see what floats best or catches the best wind" really just means "let's wait for microsoft and cisco and verisign to decide what they want to do." let's NOT do it that way. -- to unsubscribe send a message to namedroppers-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 Apr 24 10:53:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5813A7048; Fri, 24 Apr 2009 10:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 CXJOqP8w5f-O; Fri, 24 Apr 2009 10:53:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 150443A6BB7; Fri, 24 Apr 2009 10:53:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxPWQ-00066D-0a for namedroppers-data0@psg.com; Fri, 24 Apr 2009 17:49:10 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxPWB-00064I-VK for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 17:49:02 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6605E2FE960B for ; Fri, 24 Apr 2009 17:48:54 +0000 (UTC) Date: Fri, 24 Apr 2009 13:48:52 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090424174852.GL70585@shinkuro.com> References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Thu, Apr 23, 2009 at 04:05:10PM -0700, jmiller@godaddy.com wrote: > However, I must have missed the large operator's concern that you > mentioned. If you could point me in the right direction on that, I > would appreciate it. The one that I was thinking of was Paul Vixie. I think his experience with the root servers qualifies him as a large operator, but the reason I asked a question rather than saying "this is how it is" is precisely because I don't want to draw conclusions on the basis of one person's input. -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 24 11:27:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F1F3A7055; Fri, 24 Apr 2009 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.491 X-Spam-Level: X-Spam-Status: No, score=-4.491 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=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 33jkH3p5zhbe; Fri, 24 Apr 2009 11:27:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1292028C6EA; Fri, 24 Apr 2009 11:27:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxQ4H-000ATb-Oq for namedroppers-data0@psg.com; Fri, 24 Apr 2009 18:24:09 +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 1LxQ42-000ARd-5o for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 18:24:01 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n3OIMrBh010371; Fri, 24 Apr 2009 18:22:53 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n3OIMrXV010370; Fri, 24 Apr 2009 18:22:53 GMT Date: Fri, 24 Apr 2009 18:22:53 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090424182253.GA9779@vacation.karoshi.com.> References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090424174852.GL70585@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Apr 24, 2009 at 01:48:52PM -0400, Andrew Sullivan wrote: > On Thu, Apr 23, 2009 at 04:05:10PM -0700, jmiller@godaddy.com wrote: > > > However, I must have missed the large operator's concern that you > > mentioned. If you could point me in the right direction on that, I > > would appreciate it. > > The one that I was thinking of was Paul Vixie. I think his experience > with the root servers qualifies him as a large operator, but the > reason I asked a question rather than saying "this is how it is" is > precisely because I don't want to draw conclusions on the basis of one > person's input. > > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > Root Operators are in a novel position wrt being a "large operator". The zone is not large by nearly any metric. We don't do recursion or caching so that side of DNS operations is outside the relem of consideration. The one thing we root ops do get, is all the random queries that are not otherwise resolvable in the namespace... and there are quite a few of them. but I would not consider a root operator to be in the "large" camp at all... try: godaddy - enom - neustar - afilias - nic.br - twc - comcast - et.al. for large DNS operators. --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 Fri Apr 24 12:32:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FB43A688F; Fri, 24 Apr 2009 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_51=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 QkyrMVFSukqi; Fri, 24 Apr 2009 12:32:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 101BA3A6FF4; Fri, 24 Apr 2009 12:31:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxR3S-000IyV-3m for namedroppers-data0@psg.com; Fri, 24 Apr 2009 19:27:22 +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 1LxR3E-000Iuc-VB for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 19:27:15 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n3OJQ8Bh010971; Fri, 24 Apr 2009 19:26:08 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n3OJQ8jp010970; Fri, 24 Apr 2009 19:26:08 GMT Date: Fri, 24 Apr 2009 19:26:08 +0000 From: bmanning@vacation.karoshi.com To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090424192608.GC10735@vacation.karoshi.com.> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <20090424151409.GF70585@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090424151409.GF70585@shinkuro.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Apr 24, 2009 at 11:14:09AM -0400, Andrew Sullivan wrote: > Co-chair hat on. > > On Thu, Apr 23, 2009 at 09:42:48PM +0000, bmanning@vacation.karoshi.com wrote: > > the only ISP i trust implicitly is the one servicing my house.. > > > so what do I do? carry around a full-blown DNS IMR/Validator with my own > > set of keys. Yes, I'll end up getting an IP address from your handy > > DHCP/RA server (and apparently a bunch'o'worthless crap that I'll either > > dump or quarentine) ... And I'll happily build an IPSEC tunnel back to > > a trusted environment and go from there if you try and box me in. (Thanks > > Sam for pointing out how to run IP over DNS and Steve for how to run IP over > > HTTP) > > None of the above argument (and I'm including others' posts in the > thread, too -- this is just a handy paragraph on which to hang the > remark) suggests even a little bit in the way of protocol work. On > the contrary, this sounds very much like, "The protocol is done, and > we really need to get the integration and operations parts polished, > ready, and easy to use." It's easy for Bill to do the above, but the > average laptop user would stop for sure at "IMR/Validator with my own > set of keys" and maybe at "DNS". Perhaps we need howtos, operations > documents, BCP or Informational documents or such -- but this is all > deployment and coding, not new protocol. > > That sounds to me like a very strong argument for _not_ doing any more > forgery resilience or other such work, and for this WG to stop > fiddling with the security parts of the protocol: it sounds like we need > to stop distracting people who could be working on polishing the > deployment tools with shiny new protocol knobs to turn. > er - i think i've already weighed in on this on other threads... but to reiterate, the IETF's job is not to do operations or to wait upon operational folks to pick up the tokens and run w/ them. the IETF's job is to explore and docuement technical solutions. if some others are distracted by the shiny objects being talked about in the IETF, then the IETF needs to be a bit stronger on defining its standards activities.... if there is a move to restrict discussion - perhaps its time to consider other venues for doing DNS protocol work. IMHO of course. --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 Fri Apr 24 13:56:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21E23A6BD3; Fri, 24 Apr 2009 13:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 Xd3E9u4Youol; Fri, 24 Apr 2009 13:56:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C82633A6E97; Fri, 24 Apr 2009 13:55:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxSMx-0003F4-3k for namedroppers-data0@psg.com; Fri, 24 Apr 2009 20:51:35 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxSMj-0003E2-NB for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 20:51:28 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 66F4F2FE960A for ; Fri, 24 Apr 2009 20:51:20 +0000 (UTC) Date: Fri, 24 Apr 2009 16:51:18 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090424205118.GN70585@shinkuro.com> References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090424182253.GA9779@vacation.karoshi.com.> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Fri, Apr 24, 2009 at 06:22:53PM +0000, bmanning@vacation.karoshi.com wrote: > Root Operators are in a novel position wrt being a "large operator". > but I would not consider a root operator to be in the "large" camp at > all... try: Ok, so there are three importantly different meanings of "large" here, and you're quite right that we need to distinguish among them: 1. Large traffic, mostly delegation, small zone (e.g. root operator). 2. Large zones, mostly delegation, large traffic (e.g. Verisign, Afilias, &c.). 3. Large numbers of zones, mixed or little delegation, large traffic. (e.g. Go Daddy &c.) I consider "big single zone with small traffic" not to be an interesting "large" case, but I guess it might qualify too. We've heard from one example of (1) and (3), each, of these cases. That's not a great sample. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 24 16:13:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1523A6BB9; Fri, 24 Apr 2009 16:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.124 X-Spam-Level: * X-Spam-Status: No, score=1.124 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_05=-1.11, 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 o2q7wNY8lU4i; Fri, 24 Apr 2009 16:13:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 539DE3A6BCE; Fri, 24 Apr 2009 16:13:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxUVL-000EUu-Fz for namedroppers-data0@psg.com; Fri, 24 Apr 2009 23:08:23 +0000 Received: from [209.86.89.68] (helo=elasmtp-masked.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxUV7-000ETf-TZ for namedroppers@ops.ietf.org; Fri, 24 Apr 2009 23:08:15 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=rgLuTp5GwBaSKyImg9VDDL81gU3/uHKv5OmRPH/aCU4eR7PhH/yIRZVeW4W7iPUW; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.96.88] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LxUV5-0002Sp-UN; Fri, 24 Apr 2009 19:08:08 -0400 Message-ID: <49F2464E.A433A3F9@ix.netcom.com> Date: Fri, 24 Apr 2009 16:07:58 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Schmidt CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS References: <26249.1240510804@nsa.vix.com> <86048CA3B4B17E459FFD4F3F383AD88F13F27B59@fi-hel2ex01.nordiclan.net> <44750.1240535016@nsa.vix.com> <20090424104716.GA6307@vacation.karoshi.com.> <20090424124320.GF870@zaphods.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068812673f234e16462612032d8adb19fb6a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.88 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Stefan, Bill, and all, I also concur fully! Stefan Schmidt wrote: > On Fri, Apr 24, 2009 at 10:47:16AM +0000, bmanning@vacation.karoshi.com wrote: > > > > I'm not persuaded that we need the IAB to "declare victory and move on". > > There is a defined process to move protocol work to full standard and while > > that happens, I do not think it reasonable or practical to declare a > > moratorium on new ideas, proof of concept work, or technological advances. > > > ... > > I would have written about the same but probably with a worse choice of words, > so thank you Bill for beeing faster. > > > So - I'm not in favor of the IAB making any sort of pronouncement about DNSSEC, other > > than to move it along the IETF standards track. > > I concur with everything Bill wrote in his previous mail, so all there is left > for me to say now on this issue is: Me too. > > Stefan > -- > "And how would we hide a 30,000-ton submarine?" > "You hide a submarine by sinking it," Painter said angrily. > "They're designed to do that, you know." > - Ryan and Adm. Painter, "The Hunt for Red October" (Tom Clancy) > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-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 Apr 24 17:34:10 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81F13A6A1A; Fri, 24 Apr 2009 17:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 b6t1kg7J68eZ; Fri, 24 Apr 2009 17:34:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1D393A681A; Fri, 24 Apr 2009 17:34:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxVlY-000KhE-Me for namedroppers-data0@psg.com; Sat, 25 Apr 2009 00:29:12 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxVlK-000Kfv-FS for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 00:29:04 +0000 Received: from [192.168.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id A8EA6526FF4; Fri, 24 Apr 2009 17:28:56 -0700 (PDT) Cc: namedroppers@ops.ietf.org Message-Id: <56C56AD3-7F91-435F-AD5D-C6EF3A02124C@virtualized.org> From: David Conrad To: Otmar Lendl In-Reply-To: <49F192AC.4080707@nic.at> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Fri, 24 Apr 2009 17:28:54 -0700 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <49F192AC.4080707@nic.at> X-Mailer: Apple Mail (2.930.4) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 24, 2009, at 3:21 AM, Otmar Lendl wrote: > bmanning@vacation.karoshi.com wrote: >> >> so what do I do? carry around a full-blown DNS IMR/Validator with >> my own >> set of keys. > > While I agree that this is the best way to get secure DNS to your > box, I > doubt that this approach is feasible for the general public. Given existing tools, I more than agree. However if someone were to come up with a full validating resolver for (most critically) WIndows that required NO (not minimal, not easy, _no_) configuration for the normal case (a la Nominum's CNS) and which automatically fetched/ updated the root (or ITAR) trust anchor(s) in a secure(ish) fashion, the general public wouldn't even be aware they were using secure DNS. This is how it must be if we expect any level of security and penetration. Of course, stupid DNS games played by hotspot providers makes this essentially impossible right now... Regards, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From kimuxnptn@afo.net Fri Apr 24 21:43:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F7C3A657C for ; Fri, 24 Apr 2009 21:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.259 X-Spam-Level: X-Spam-Status: No, score=-12.259 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 GGMfOMs-I6Dn for ; Fri, 24 Apr 2009 21:43:42 -0700 (PDT) Received: from mail1.tradeonly.co.uk (mail1.tradeonly.co.uk [88.208.221.7]) by core3.amsl.com (Postfix) with SMTP id 4A58E3A68A1 for ; Fri, 24 Apr 2009 21:43:40 -0700 (PDT) To: " Date: Fri, 24 Apr 2009 21:43:40 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From kanga@aatf-africa.org Fri Apr 24 22:34:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A7E3A688D for ; Fri, 24 Apr 2009 22:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.464 X-Spam-Level: X-Spam-Status: No, score=-7.464 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 XtZ7pJHIBw2s for ; Fri, 24 Apr 2009 22:34:43 -0700 (PDT) Received: from host86-166-219-54.range86-166.btcentralplus.com (host86-166-219-54.range86-166.btcentralplus.com [86.166.219.54]) by core3.amsl.com (Postfix) with SMTP id 912C83A67F6 for ; Fri, 24 Apr 2009 22:34:42 -0700 (PDT) To: dnsext-archive@ietf.org Subject: from dnsext-archive@ietf.org From: dnsext-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090425053442.912C83A67F6@core3.amsl.com> Date: Fri, 24 Apr 2009 22:34:42 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 9, 71599 AZ Amsterdam, The Netherlands
From owner-namedroppers@ops.ietf.org Fri Apr 24 23:07:03 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4BF3A68D6; Fri, 24 Apr 2009 23:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.731 X-Spam-Level: *** X-Spam-Status: No, score=3.731 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_BLUEYON=1.4, HELO_MISMATCH_UK=1.749, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 DA5S3cBiYUDE; Fri, 24 Apr 2009 23:07:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19CCE3A6966; Fri, 24 Apr 2009 23:06:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lxavu-000GGr-31 for namedroppers-data0@psg.com; Sat, 25 Apr 2009 06:00:14 +0000 Received: from [195.188.213.5] (helo=smtp-out2.blueyonder.co.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lxavb-000GDN-KW for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 06:00:05 +0000 Received: from [172.23.170.136] (helo=anti-virus01-07) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1LxavZ-0006YU-J3 for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 06:59:53 +0100 Received: from [82.46.70.191] (helo=GeorgeLaptop) by asmtp-out4.blueyonder.co.uk with esmtpa (Exim 4.52) id 1LxavZ-0004il-4Y for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 06:59:53 +0100 Message-ID: <1F521A0FC72142E28364A5933B55C352@localhost> From: "George Barwood" To: References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <20090424151409.GF70585@shinkuro.com> Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Sat, 25 Apr 2009 06:59:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andrew > That sounds to me like a very strong argument for _not_ doing any more > forgery resilience or other such work, and for this WG to stop > fiddling with the security parts of the protocol: it sounds like we need > to stop distracting people who could be working on polishing the > deployment tools with shiny new protocol knobs to turn. I do wonder at some of the complacency being shown. A couple of recent articles from The Register << http://www.theregister.co.uk/2008/11/12/mockapetris_interview/ "An attack might be possible in five hours with the patch. That's much better than the minutes an attack might have taken before but systems are still not really protected. IT's bought time without solving the underlying problem," Mockapetris told El Reg. Mockapetris helped invent the DNS system in the 1980s. The original intention was to get systems up and running and add security features later but the process has proved far more protracted than he ever imagined. Mockapetris now reckons DNSSec might eventually be applied in 2015 but given he said five years ago that the technology would be "ubiquitous" by 2008 we ought to treat such predictions with caution. http://www.theregister.co.uk/2009/04/22/bandesco_cache_poisoning_attack/ One of Brazil's biggest banks has suffered an attack that redirected its customers to fraudulent websites that attempted to steal passwords and install malware, according to an unconfirmed report. >> IMO we are fiddling while Rome burns. We are not sure when DNSSEC will be fully deployed, but there is a real live security problem here, and all of the options to fix it need to be explored. If there is are options to fix this in less than 15 years, I think they should be explored. Personally I have deployed a resolver for myself personally and my company that is not subject to spoofing, solving my problems today. I would like to see such resolvers more generally available. Official guidance from the IETF on this would help ( given than DNS is an IETF standard ). George Barwood -- to unsubscribe send a message to namedroppers-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 Apr 25 00:40:16 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513193A67FF; Sat, 25 Apr 2009 00:40:16 -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.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, J_CHICKENPOX_32=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 HQkRGOIoeClO; Sat, 25 Apr 2009 00:40:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 646183A69B8; Sat, 25 Apr 2009 00:40:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxcQH-000LrR-7w for namedroppers-data0@psg.com; Sat, 25 Apr 2009 07:35:41 +0000 Received: from [83.136.33.3] (helo=labs.nic.at) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxcQ3-000LqO-28 for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 07:35:34 +0000 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1LxcPx-00015l-00; Sat, 25 Apr 2009 09:35:21 +0200 Date: Sat, 25 Apr 2009 09:35:21 +0200 From: Otmar Lendl To: Andrew Sullivan Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090425073521.GA4146@nic.at> References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> <20090424205118.GN70585@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090424205118.GN70585@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 2009/04/24 22:04, Andrew Sullivan wrote: > > Ok, so there are three importantly different meanings of "large" here, > and you're quite right that we need to distinguish among them: > You're completely missing the resolver side. Big consumer ISPs like Comcast, Verizon, T-Online, BT, ... all run massive clusters of resolvers. You also need to consider what EDNS0-ping means to them. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg -- to unsubscribe send a message to namedroppers-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 Apr 25 00:45:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D963A6BE1; Sat, 25 Apr 2009 00:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 tFKP7I5J0hbn; Sat, 25 Apr 2009 00:45:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B01DF3A6BD5; Sat, 25 Apr 2009 00:45:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxcXL-000MT0-BN for namedroppers-data0@psg.com; Sat, 25 Apr 2009 07:42:59 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxcX9-000MSG-RX for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 07:42:53 +0000 Received: from [192.168.100.63] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id DE4E5C2DA3; Sat, 25 Apr 2009 08:42:44 +0100 (BST) Date: Sat, 25 Apr 2009 08:43:34 +0100 From: Alex Bligh Reply-To: Alex Bligh To: David Conrad , Otmar Lendl cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <918B03AD8DA03AC986FE1063@nimrod.local> In-Reply-To: <56C56AD3-7F91-435F-AD5D-C6EF3A02124C@virtualized.org> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <49F192AC.4080707@nic.at> <56C56AD3-7F91-435F-AD5D-C6EF3A02124C@virtualized.org> 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 24 April 2009 17:28:54 -0700 David Conrad wrote: > Of course, stupid DNS games played by hotspot providers makes this > essentially impossible right now... Stupid games played by hotspot providers would actually prove the case. In your "no configuration Windows tool" scenario, a pretty box pops up and says "Warning: your internet connection cannot be reliably secured" and if you click "Advanced" it says "DNSSEC failure". If / when the hotspot providers cease their stupid games so that at least when you are paid up and logged on it correctly processes DNSSEC (which is quite possible), this would only happen when being redirected to their logon page. IE surely interception and alteration of DNS is exactly what such a tool should be seeking to identify? Possibly slightly of topic, but it's ages since I looked at this, but I had /thought/ that most hotspot providers did not futz with DNS any more because various versions of Windows did not expire their DNS cache properly, so the intercepted values (and values from earlier sessions) stuck around. I had thought what they did was shut of access on everything to anything outside their walled garden, did an HTTP redirect on port 80 to their servers, but their resolving server on port 53 would actually resolve external names correctly. This explains why various methods of tunneling IP over DNS lookups are more successful than one might have thought. 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 mark.wassmer@accenturehrservices.com Sat Apr 25 09:41:44 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A923A6AE1 for ; Sat, 25 Apr 2009 09:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.17 X-Spam-Level: X-Spam-Status: No, score=-12.17 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 jkBLEzEJzO3f for ; Sat, 25 Apr 2009 09:41:37 -0700 (PDT) Received: from amscan-uk.co.uk (unknown [85.107.114.143]) by core3.amsl.com (Postfix) with SMTP id 6CCFB3A6DF3 for ; Sat, 25 Apr 2009 09:41:12 -0700 (PDT) To: " Date: Sat, 25 Apr 2009 09:41:12 -0700 (PDT)
Men's Health wirzpBuild Maximum MUSCLE, STRENGTH, and POWER!
Try It FREE for 21 Days! ORDER NOW! Plus, get 2 FREE Bonus Gifts!
Dear dnsext-archive

Men's Health recommends


FREE gifts reserved for you: dnsext-archive@ietf.org
If you would prefer not to receive future information about special offers from Men's Health,
you may Unsubscribe.


Customer Service Department, 33 East Minor Street, Emmaus, PA 18098


Copyright, Men's Health
From owner-namedroppers@ops.ietf.org Sat Apr 25 11:53:02 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7893A69CF; Sat, 25 Apr 2009 11:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 TTHlEkGXdM4d; Sat, 25 Apr 2009 11:53:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7773F3A6820; Sat, 25 Apr 2009 11:53:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lxmtc-0001ft-SP for namedroppers-data0@psg.com; Sat, 25 Apr 2009 18:46:40 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LxmtQ-0001eS-8e for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 18:46:34 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4F35AA1017; Sat, 25 Apr 2009 18:46:21 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Otmar Lendl cc: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS In-Reply-To: Your message of "Sat, 25 Apr 2009 09:35:21 +0200." <20090425073521.GA4146@nic.at> References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> <20090424205118.GN70585@shinkuro.com> <20090425073521.GA4146@nic.at> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Sat, 25 Apr 2009 18:46:21 +0000 Message-ID: <62707.1240685181@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > Date: Sat, 25 Apr 2009 09:35:21 +0200 > From: Otmar Lendl > > ... > You're completely missing the resolver side. > > Big consumer ISPs like Comcast, Verizon, T-Online, BT, ... all run > massive clusters of resolvers. You also need to consider what EDNS0-ping > means to them. i'm all for considering other endpoint types than "large responder", but the context for evaluation has to be the whole system, not one implementation or one installation or one kind of installation. DNS is already very large and has a lot of moving parts. something like PING would have a systemic effect (just as "just fall back to TCP" or "just use TCP" would have). our remit is to consider that whole system. if looking at installation types is a helpful lense then let's look at it. but we have to evaluate systemically. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From kwaka@akingump.com Sat Apr 25 12:36:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B6B3A6A0E for ; Sat, 25 Apr 2009 12:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 9I7ZpXisMvbU for ; Sat, 25 Apr 2009 12:36:37 -0700 (PDT) Received: from 201-13-121-171.dsl.telesp.net.br (201-13-121-171.dsl.telesp.net.br [201.13.121.171]) by core3.amsl.com (Postfix) with SMTP id 36F943A69B5 for ; Sat, 25 Apr 2009 12:36:27 -0700 (PDT) To: " Date: Sat, 25 Apr 2009 12:36:27 -0700 (PDT)

Read more
Copyright
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Sun Apr 26 02:27:00 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3963A6A33; Sun, 26 Apr 2009 02:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.273 X-Spam-Level: * X-Spam-Status: No, score=1.273 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_43=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 F7yZ+y++hHtY; Sun, 26 Apr 2009 02:26:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 70F1C3A686E; Sun, 26 Apr 2009 02:26:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ly0WH-0005UP-Px for namedroppers-data0@psg.com; Sun, 26 Apr 2009 09:19:29 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ly0Vt-0005SO-TR for namedroppers@ops.ietf.org; Sun, 26 Apr 2009 09:19:23 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) id 1Ly0VX-0004ca-7t; Sun, 26 Apr 2009 11:18:43 +0200 Received: from fweimer by bfk.de with local id 1Ly0Vo-0005v4-6L; Sun, 26 Apr 2009 11:19:00 +0200 To: Shane Kerr Cc: namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> <82hc0fa4ed.fsf@mid.bfk.de> <49F0D370.2060007@ca.afilias.info> From: Florian Weimer Date: Sun, 26 Apr 2009 11:19:00 +0200 In-Reply-To: <49F0D370.2060007@ca.afilias.info> (Shane Kerr's message of "Thu, 23 Apr 2009 22:45:36 +0200") Message-ID: <82eivfydq3.fsf@mid.bfk.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: * Shane Kerr: >> I think it's not really that much more work to put a DS record there >> instead of an EDNS0OPT record, so I don't think this approach offers a >> got trade-off. > > Well, except that one needs to actually sign the parent zone for > there to be any point in putting a DS record in it, which *is* a lot > more work. It shouldn't be more work. If you keep your keys online, it should suffice to flip a switch in your primary name server. (Implementations aren't quite there yet, though.) You don't need any external communication and any new interfaces for this step. Once you want to install a DS in the parent, it's going to be somewhat more tricky. The real fun starts if you want to publish DS records for (many) child zones. This used to be different when you were supposed to keep your private key material off line, but times have changed. To repeat, I think that any mechanism which requires new data in parent zones is not much easier to implement than DNSSEC. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From ninabirla@alrostamani.ae Sun Apr 26 05:26:08 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91B43A67D2 for ; Sun, 26 Apr 2009 05:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.432 X-Spam-Level: X-Spam-Status: No, score=-11.432 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RELAY_IS_222=2.179, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 b2BpY3nSqaEz for ; Sun, 26 Apr 2009 05:26:07 -0700 (PDT) Received: from p5207-ipad205funabasi.chiba.ocn.ne.jp (p5207-ipad205funabasi.chiba.ocn.ne.jp [222.146.100.207]) by core3.amsl.com (Postfix) with SMTP id 94EA23A6DFD for ; Sun, 26 Apr 2009 05:25:58 -0700 (PDT) To: dnsext-archive@ietf.org Subject: RE: Q&A Doctor Gavin From: dnsext-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090426122559.94EA23A6DFD@core3.amsl.com> Date: Sun, 26 Apr 2009 05:25:58 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 6, 69444 AZ Amsterdam, The Netherlands
From massimiliano.nicosia@accenture.com Sun Apr 26 06:35:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CAF3A6D54 for ; Sun, 26 Apr 2009 06:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.13 X-Spam-Level: X-Spam-Status: No, score=-12.13 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 hBSjhueJrVor for ; Sun, 26 Apr 2009 06:35:11 -0700 (PDT) Received: from 5ad693ee.bb.sky.com (5ad693ee.bb.sky.com [90.214.147.238]) by core3.amsl.com (Postfix) with SMTP id 2D52B3A6E0B for ; Sun, 26 Apr 2009 06:35:09 -0700 (PDT) To: " Date: Sun, 26 Apr 2009 06:35:09 -0700 (PDT)

Read more
Copyright
Subscribe to Men's Health Today!
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Sun Apr 26 13:52:45 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF82E3A6C3D; Sun, 26 Apr 2009 13:52:44 -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 EXh53Rn526qe; Sun, 26 Apr 2009 13:52:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F21D83A68CE; Sun, 26 Apr 2009 13:52:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyBEg-0003Li-6c for namedroppers-data0@psg.com; Sun, 26 Apr 2009 20:46:02 +0000 Received: from [2001:888:1037:1337::53:53] (helo=burnout.bakker.net) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyBES-0003JV-7Y for namedroppers@ops.ietf.org; Sun, 26 Apr 2009 20:45:55 +0000 Received: by burnout.bakker.net (Postfix, from userid 910) id CAD7DF1842; Sun, 26 Apr 2009 22:45:45 +0200 (CEST) Date: Sun, 26 Apr 2009 22:45:45 +0200 From: niels=ietfops@bakker.net (Niels Bakker) To: namedroppers@ops.ietf.org Subject: Re: Publishing NS features in the DNS, was Re: [dnsext] Re: Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090426204545.GR9502@burnout.tpb.net> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <20090423072539.GC6975@nic.fr> <86048CA3B4B17E459FFD4F3F383AD88F13F27B4D@fi-hel2ex01.nordiclan.net> <49F06426.4000702@ca.afilias.info> <82hc0fa4ed.fsf@mid.bfk.de> <49F0D370.2060007@ca.afilias.info> <82eivfydq3.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <82eivfydq3.fsf@mid.bfk.de> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: * fweimer@bfk.de (Florian Weimer) [Sun 26 Apr 2009, 11:51 CEST]: >* Shane Kerr: >> Well, except that one needs to actually sign the parent zone for >> there to be any point in putting a DS record in it, which *is* a lot >> more work. >It shouldn't be more work. If you keep your keys online, it should >suffice to flip a switch in your primary name server. [..] >This used to be different when you were supposed to keep your private >key material off line, but times have changed. Wait, what? Has the Internet really become a more secure place in the past 15 years? -- Niels. -- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From majordomo@alfafar.com Sun Apr 26 18:24:35 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5FA3A68DF for ; Sun, 26 Apr 2009 18:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.766 X-Spam-Level: X-Spam-Status: No, score=-20.766 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_HELO_EQ_DSL_3=1.022, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 G5jZP8aXMNUv for ; Sun, 26 Apr 2009 18:24:34 -0700 (PDT) Received: from dsl-emcali-190.1.222.5.emcali.net.co (dsl-emcali-190.1.222.5.emcali.net.co [190.1.222.5]) by core3.amsl.com (Postfix) with SMTP id 375EE3A68E7 for ; Sun, 26 Apr 2009 18:24:32 -0700 (PDT) To: " Date: Sun, 26 Apr 2009 18:24:32 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Mon Apr 27 03:56:13 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF733A67A3; Mon, 27 Apr 2009 03:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.695 X-Spam-Level: * X-Spam-Status: No, score=1.695 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 cUcekqN5D6LT; Mon, 27 Apr 2009 03:56:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 399693A691F; Mon, 27 Apr 2009 03:55:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyOPe-000375-Bg for namedroppers-data0@psg.com; Mon, 27 Apr 2009 10:50:14 +0000 Received: from [94.198.152.69] (helo=arn1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyOPQ-00034M-JZ for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 10:50:07 +0000 Received: from sidn.nl ([192.168.2.12]) by arn1-kamx.sidn.nl with ESMTP id n3RAnwhA020636 for ; Mon, 27 Apr 2009 12:49:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [dnsext] we need an IAB statement on Secure DNS Date: Mon, 27 Apr 2009 12:50:24 +0200 Message-ID: <850A39016FA57A4887C0AA3C8085F949C4F3F6@KAEVS1.SIDN.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] we need an IAB statement on Secure DNS Thread-Index: AcnFIPa4YIZCUCWoT4aus8HBzyhgJQB/4n/Q References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> <20090424205118.GN70585@shinkuro.com> From: "Antoin Verschuren" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkkgY29u c2lkZXIgbXlzZWxmIGluIGdyb3VwIDIsIGFuZCBJJ3ZlIGV4cHJlc3NlZCBteSBjb25jZXJucyB3 aXRoIHRyYWZmaWMgcmVnYXJkaW5nIEVETlMwIFBpbmcuDQoNCk9uZSBtb3JlIHRoaW5nIHRoYXQg Y29tZXMgdG8gbWluZCBhcmUgb3RoZXIgb3BlcmF0aW9uYWwgaXNzdWVzIHRoYXQgQW5kcmV3IHBv aW50ZWQgb3V0Lg0KTW9uaXRvcmluZyBvciBhbmFseXppbmcgdHJhZmZpYyB3aWxsIGNoYW5nZSB3 aXRoIEVORFMwIFBpbmcsIGFuZCB0aHVzIGhhcyBvcGVyYXRpb25hbCBpbXBhY3QuDQpXaGVyZSBJ IGNhbiBub3cgZWFzaWx5IHByZWRpY3QgdGhhdCByZXNlbmRpbmcgcXVlcmllcyBpcyBub3Qgbm9y bWFsIHJlc29sdmVyIGJlaGF2aW9yIHRoYXQgbmVlZHMgaW52ZXN0aWdhdGluZywgaW50cm9kdWNp bmcgcmUtcXVlcnlpbmcgYnkgcHJvdG9jb2wgZGVmYXVsdCB3aWxsIG1ha2UgbWUgbmVlZCB0byBj aGFuZ2UgbXkgZGV0ZWN0aW9uIGFsZ29yaXRobXMuDQoNCkFzIGEgdmVyeSBzaW1wbGUgZXhhbXBs ZSwgcmUtcXVlcnlpbmcgdGhlIHNhbWUgcXVlcnkgZnJvbSB0aGUgc2FtZSBob3N0IHdpdGggc3Bl Y2lmaWMgYXR0cmlidXRlcyBub3cgaW5kaWNhdGVzIGJvdG5ldCBhYnVzZSB3aXRoIHRoZSBjbGVh ciBpbnRlbmQgbm90IHRvIHVzZSB0aGUgcmVzdWx0IGZvciB0aGUgY29ycmVjdCB3b3JraW5nIG9m IHRoZSBJbnRlcm5ldCwgYnV0IG1lcmVseSBkbyB0aGUgcmUtcXVlcnlpbmcgYmVjYXVzZSBpdCBk b2VzIG5vdCBjb3N0IHRoZSBib3RuZXQgb3BlcmF0b3IgdG8gZG8gdGhlIGV4dHJhIHF1ZXJpZXMu IFRoZSBvbmx5IHB1cnBvc2UgaXMgdG8gZG8gaGFybSBvciB0byBnZXQgYSByZXN1bHQgdGhlIERO UyBpcyBub3QgaW50ZW5kZWQgZm9yLiBCdXQgaXQgZG9lcyBjb3N0IHVzLg0KSW50cm9kdWNpbmcg cmUtcXVlcnlpbmcgd2l0aCB0aGUgaW50ZW5kIHRvIGltcHJvdmUgdGhlIGNvcnJlY3Qgd29ya2lu ZyBvZiB0aGUgaW5mcmFzdHJ1Y3R1cmUgaXMgc29tZXRoaW5nIEkgY2Fubm90IGRpc2NhcmQgb3Ig ZmlsdGVyIG91dCBzbyBJIG11c3QgYWRqdXN0IG15IGRldGVjdGlvbiBhbGdvcml0aG1zLiAgDQoN CkkgZG8gbm90IHF1ZXN0aW9uIHRoZSBpbmNyZWFzZSBpbiB0cmFmZmljIHRoYXQgaXMgbmVlZGVk IHRvIGdldCBhbnkgc2VjdXJpdHkgaW4gcGxhY2UuDQpXZSBjYW4gaGFuZGxlIHRoYXQuDQpCdXQg SSBkbyBxdWVzdGlvbiBpZiB3ZSBuZWVkIHRvIGdldCBtdWx0aXBsZSBkaWZmZXJlbnQgb3Zlcmxh cHBpbmcgc2VjdXJpdHkgbWVhc3VyZXMgaW4gcGxhY2UgdGhhdCBhbGwgbmVlZCBleHRyYSB0cmFm ZmljLCBlYWNoIG9uZSBhZGRyZXNzaW5nIGEgZGlmZmVyZW50IGF0dGFjayB2ZWN0b3IuIEFuZCBl YWNoIG9uZSBkZWNsYXJpbmcgaXQgb25seSBjb3N0cyBhIGZldyBiaXRzLiBNYW55IGZldyBiaXRz IG1ha2UgbWFueSBiaXRzLg0KDQpMZXQncyBtYWtlIGl0IGFuIGVmZmljaWVudCBhcyBwb3NzaWJs ZSBwcm90b2NvbC4NCg0KQW50b2luIFZlcnNjaHVyZW4NCg0KVGVjaG5pY2FsIFBvbGljeSBBZHZp c29yDQpTSURODQpVdHJlY2h0c2V3ZWcgMzEwDQpQTyBCb3ggNTAyMg0KNjgwMiBFQSBBcm5oZW0N ClRoZSBOZXRoZXJsYW5kcw0KDQpUICszMSAyNiAzNTI1NTAwDQpGICszMSAyNiAzNTI1NTA1DQpN ICszMSA2IDIzMzY4OTcwDQpFIGFudG9pbi52ZXJzY2h1cmVuQHNpZG4ubmwNClcgaHR0cDovL3d3 dy5zaWRuLm5sLw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3du ZXItbmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLQ0KPiBuYW1lZHJvcHBl cnNAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3IFN1bGxpdmFuDQo+IFNlbnQ6IEZy aWRheSwgQXByaWwgMjQsIDIwMDkgMTA6NTEgUE0NCj4gVG86IG5hbWVkcm9wcGVyc0BvcHMuaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkbnNleHRdIHdlIG5lZWQgYW4gSUFCIHN0YXRlbWVudCBv biBTZWN1cmUgRE5TDQo+IA0KPiBPbiBGcmksIEFwciAyNCwgMjAwOSBhdCAwNjoyMjo1M1BNICsw MDAwLCBibWFubmluZ0B2YWNhdGlvbi5rYXJvc2hpLmNvbQ0KPiB3cm90ZToNCj4gPiAJUm9vdCBP cGVyYXRvcnMgYXJlIGluIGEgbm92ZWwgcG9zaXRpb24gd3J0IGJlaW5nIGEgImxhcmdlIG9wZXJh dG9yIi4NCj4gDQo+ID4gCWJ1dCBJIHdvdWxkIG5vdCBjb25zaWRlciBhIHJvb3Qgb3BlcmF0b3Ig dG8gYmUgaW4gdGhlICJsYXJnZSIgY2FtcA0KPiBhdA0KPiA+IAlhbGwuLi4gIHRyeToNCj4gDQo+ IE9rLCBzbyB0aGVyZSBhcmUgdGhyZWUgaW1wb3J0YW50bHkgZGlmZmVyZW50IG1lYW5pbmdzIG9m ICJsYXJnZSIgaGVyZSwNCj4gYW5kIHlvdSdyZSBxdWl0ZSByaWdodCB0aGF0IHdlIG5lZWQgdG8g ZGlzdGluZ3Vpc2ggYW1vbmcgdGhlbToNCj4gDQo+IDEuICBMYXJnZSB0cmFmZmljLCBtb3N0bHkg ZGVsZWdhdGlvbiwgc21hbGwgem9uZSAoZS5nLiByb290IG9wZXJhdG9yKS4NCj4gDQo+IDIuICBM YXJnZSB6b25lcywgbW9zdGx5IGRlbGVnYXRpb24sIGxhcmdlIHRyYWZmaWMgKGUuZy4gVmVyaXNp Z24sDQo+ICAgICAgICAgQWZpbGlhcywgJmMuKS4NCj4gDQo+IDMuICBMYXJnZSBudW1iZXJzIG9m IHpvbmVzLCBtaXhlZCBvciBsaXR0bGUgZGVsZWdhdGlvbiwgbGFyZ2UgdHJhZmZpYy4NCj4gICAg ICAgICAoZS5nLiBHbyBEYWRkeSAmYy4pDQo+IA0KPiBJIGNvbnNpZGVyICJiaWcgc2luZ2xlIHpv bmUgd2l0aCBzbWFsbCB0cmFmZmljIiBub3QgdG8gYmUgYW4NCj4gaW50ZXJlc3RpbmcgImxhcmdl IiBjYXNlLCBidXQgSSBndWVzcyBpdCBtaWdodCBxdWFsaWZ5IHRvby4gIFdlJ3ZlDQo+IGhlYXJk IGZyb20gb25lIGV4YW1wbGUgb2YgKDEpIGFuZCAoMyksIGVhY2gsIG9mIHRoZXNlIGNhc2VzLiAg VGhhdCdzDQo+IG5vdCBhIGdyZWF0IHNhbXBsZS4NCj4gDQo+IEENCj4gDQo+IA0KPiAtLQ0KPiBB bmRyZXcgU3VsbGl2YW4NCj4gYWpzQHNoaW5rdXJvLmNvbQ0KPiBTaGlua3VybywgSW5jLg0KPiAN Cj4gLS0NCj4gdG8gdW5zdWJzY3JpYmUgc2VuZCBhIG1lc3NhZ2UgdG8gbmFtZWRyb3BwZXJzLXJl cXVlc3RAb3BzLmlldGYub3JnIHdpdGgNCj4gdGhlIHdvcmQgJ3Vuc3Vic2NyaWJlJyBpbiBhIHNp bmdsZSBsaW5lIGFzIHRoZSBtZXNzYWdlIHRleHQgYm9keS4NCj4gYXJjaGl2ZTogPGh0dHA6Ly9v cHMuaWV0Zi5vcmcvbGlzdHMvbmFtZWRyb3BwZXJzLz4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVS RS0tLS0tDQpWZXJzaW9uOiA5LjYuMyAoQnVpbGQgMzAxNykNCg0Kd3NCVkF3VUJTZldOOERxSHJN ODgzQWduQVFpbG1nZi9iMmxrNFp2aDFyTUh0MitVb29Zc2J1MG5NR2xKSnVVYg0KVE8rRm44RXNa bFNsb2d1K2Q5T2dkbERGWjYvSTZOL0xuM2Jsakl3M2h6VmFRVkNvS05qeEFLY0hTRHFGaEFjVg0K Rkt6WktHYlEwWHA0RnlqSjdpR3JoZjBMUFJEQXFqbStuZ3hhNVF3K2g1aStqeFROWnU1VVFFaXI2 L1RhalVHUw0KbEJqTXhNVE5iZ3JPN2pzZzUxQXJrOXhQR0Q3Um92c3FwUFY1SjRFQUJFLzlieWJF cTdqZHZaei9BR0NrQ2VzOQ0KS0JFQW5MSzV5d2d1UzhlSUNOVU9PS0dZTU9PQWhRQzV6bWxrNmQx TExCVTJDSU1pTkEzVTRnTHNrWGVzRGowWQ0KOG14bmZmSDNkd3R6UDg1K01IdXZOU3VCSzY4Rktt Q1ZxY3h3ZnRvU0oxWkprM3dmbExOYllBPT0NCj0zclhzDQotLS0tLUVORCBQR1AgU0lHTkFUVVJF LS0tLS0NCg0K -- to unsubscribe send a message to namedroppers-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 Apr 27 06:29:28 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7498F28C0D9; Mon, 27 Apr 2009 06:29:28 -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 DlEnc8TWZghu; Mon, 27 Apr 2009 06:29:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3FAC3A6E7D; Mon, 27 Apr 2009 06:29:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyQqA-000GQS-BN for namedroppers-data0@psg.com; Mon, 27 Apr 2009 13:25:46 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyQpw-000GPc-Sw for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 13:25:39 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3RDPTKr002792 for ; Mon, 27 Apr 2009 09:25:29 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n3RDPTrk002791 for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 09:25:29 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:ba:21f:c6ff:fe69:9eea] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lxkc0-000Fai-5k for namedroppers@ops.ietf.org; Sat, 25 Apr 2009 16:20:26 +0000 Received: from [10.0.1.106] (cpe-67-9-133-211.austin.res.rr.com [67.9.133.211]) by toccata.fugue.com (Postfix) with ESMTPSA id 3606634E425B for ; Sat, 25 Apr 2009 09:20:21 -0700 (MST) Message-Id: <6E321631-924C-4B73-9017-A2F8AFC315AC@fugue.com> From: Ted Lemon To: Namedroppers WG In-Reply-To: <918B03AD8DA03AC986FE1063@nimrod.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Sat, 25 Apr 2009 11:20:17 -0500 References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <49F192AC.4080707@nic.at> <56C56AD3-7F91-435F-AD5D-C6EF3A02124C@virtualized.org> <918B03AD8DA03AC986FE1063@nimrod.local> X-Mailer: Apple Mail (2.930.3) X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 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. ] On Apr 25, 2009, at 2:43 AM, Alex Bligh wrote: > If / when the hotspot providers cease their stupid games so that at > least > when you are paid up and logged on it correctly processes DNSSEC > (which is quite possible), this would only happen when being > redirected > to their logon page. From a security perspective, a UI that you habitually bypass is a disaster. I *hope* nobody implements it like that. It should be pretty easy to detect a hotspot redirect as a special event and do the right thing. -- to unsubscribe send a message to namedroppers-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 Apr 27 06:33:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13C528C0D9; Mon, 27 Apr 2009 06:33:09 -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 KZYV8ISVUwsF; Mon, 27 Apr 2009 06:33:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E5C528C12D; Mon, 27 Apr 2009 06:32:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyQvF-000H31-0C for namedroppers-data0@psg.com; Mon, 27 Apr 2009 13:31:01 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyQtV-000Gmj-FZ for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 13:29:36 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3RDTB8K002839 for ; Mon, 27 Apr 2009 09:29:11 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n3RDTBEV002838 for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 09:29:11 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:888:1037:1337::53:53] (helo=burnout.bakker.net) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyQWS-000EpM-7z for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 13:05:31 +0000 Received: by burnout.bakker.net (Postfix, from userid 910) id 9FFF8F1839; Mon, 27 Apr 2009 15:05:22 +0200 (CEST) Date: Mon, 27 Apr 2009 15:05:22 +0200 From: niels@bakker.net (Niels Bakker) To: Subject: Re: [dnsext] we need an IAB statement on Secure DNS Message-ID: <20090427130522.GS9502@burnout.tpb.net> References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> <20090424205118.GN70585@shinkuro.com> <850A39016FA57A4887C0AA3C8085F949C4F3F6@KAEVS1.SIDN.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <850A39016FA57A4887C0AA3C8085F949C4F3F6@KAEVS1.SIDN.local> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 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. ] * Antoin.Verschuren@sidn.nl (Antoin Verschuren) [Mon 27 Apr 2009, 13:18 CEST]: >As a very simple example, re-querying the same query from the same host >with specific attributes now indicates botnet abuse with the clear >intend not to use the result for the correct working of the Internet, >but merely do the re-querying because it does not cost the botnet >operator to do the extra queries. The only purpose is to do harm or to >get a result the DNS is not intended for. But it does cost us. You're divining quite a bit of information from two nearly identical packets. >Introducing re-querying with the intend to improve the correct working >of the infrastructure is something I cannot discard or filter out so I >must adjust my detection algorithms. Your filter is clearly operating way above and beyond the technical. Adjusting it to incremental improvements in the DNS protocol seems only fair in my eyes. (I can only assume DNSSEC queries will require much more in-depth changes to your IDS tools.) >I do not question the increase in traffic that is needed to get any >security in place. >We can handle that. That's good. Much in the same vein, I assume your servers are already handling the extra traffic for e.g. AAAA queries fine. >But I do question if we need to get multiple different overlapping >security measures in place that all need extra traffic, each one >addressing a different attack vector. And each one declaring it only >costs a few bits. Many few bits make many bits. Are you advocating to let some attack vectors go unaddressed? >Let's make it an efficient as possible protocol. And what about the people who attach TTLs lower than what SIDN publishes in the .nl zone to their NS records returned with glue? They cause more traffic on ccTLD servers than they otherwise would have gotten. Are you willing to take as vocal a stand against that practice? -- Niels. -- -- to unsubscribe send a message to namedroppers-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 Apr 27 06:42:37 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3C93A6F85; Mon, 27 Apr 2009 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, 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 XngGDLlA837P; Mon, 27 Apr 2009 06:42:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F3CF73A6F7F; Mon, 27 Apr 2009 06:42:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyR4B-000HwG-RB for namedroppers-data0@psg.com; Mon, 27 Apr 2009 13:40:15 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyR3y-000Huj-VI for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 13:40:08 +0000 Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A76E82FE960A for ; Mon, 27 Apr 2009 13:39:59 +0000 (UTC) Date: Mon, 27 Apr 2009 09:39:57 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Message-ID: <20090427133957.GB73201@shinkuro.com> References: <200904221507.n3MF7G6J047453@stora.ogud.com> <49EF5FC2.3070007@nic.at> <0BA7A4FD-3857-49DE-B061-F941B5ECBD47@icsi.berkeley.edu> <20090423132036.GA68360@shinkuro.com> <20090423210314.GL68912@shinkuro.com> <20090423214248.GB32543@vacation.karoshi.com.> <20090424151409.GF70585@shinkuro.com> <1F521A0FC72142E28364A5933B55C352@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F521A0FC72142E28364A5933B55C352@localhost> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Dear colleagues, On Sat, Apr 25, 2009 at 06:59:51AM +0100, George Barwood wrote: > I do wonder at some of the complacency being shown. I want to make perfectly clear, since it apparently wasn't (I received some other notes off-list about this as well) that my note was not intended to be any kind of quasi-ruling on whether we should take on this work. I was instead intending to point out that the arguments so far have been pretty weak. As I have been able to understand it, the primary argument in favour of EDNS0 Ping (or 0x20, for that matter) is that it's easier to get standardized and deployed than DNSSEC. I don't find that argument compelling: 1. Some people -- primarily, those who operate "infrastructure servers", for want of a better term -- are expressing considerable concern about the operational effects of the change. 2. None of these techniques have attracted anything that could be called consensus yet. Instead, it appears there are two camps with some calling adoption actually harmful. 3. We have another technique (DNSSEC) that many people seem to think solves the same set of problems. There is disagreement about the relative costs of the proposed techniques and DNSSEC deployment. 4. DNSSEC is already standardized, and some deployment has started. 5. Others within the IETF might reasonably ask why we have multiple, redundant, 80% solutions for security problems that are already solved by an existing protocol. The premises 1-5 make me think that the faster-and-cheaper claim about these alternative techniques may be a stronger claim than is warranted. Since faster-and-cheaper is so far the only real premise doing any work in the argument in favour of these alternative techniques, if that premise isn't obviously true, then it's not obvious we should take on the additional work. This has nothing to do with the merits of the individual approaches or anything like that: it's an engineering trade-off question, where one has to ask whether adding something new is a good idea given all other considerations. If (3), above, is false -- that is, if any of these techniques solves a problem that is currently not solved by DNSSEC -- then the arguments change. But so far, I haven't seen those arguing for the alternative techniques on list making the claim that there's a hole in DNSSEC that these alternatives can fill. (There might be.) In addition, > IMO we are fiddling while Rome burns. > > We are not sure when DNSSEC will be fully deployed, but there is a real live > security problem here, and all of the options to fix it need to be explored. I find the above argument completely bizarre. To beat the metaphor to dealth, it's as though we're standing around in the midst of dozens of pails of water, while Rome burns, and complaining that we don't have a pail-refill protocol and we don't have any buckets of sand. Also, airlift helicopters haven't been invented. One thing we could do is start using the water buckets we have. We have DNSSEC. Rather than wringing our hands about not being sure when DNSSEC will be fully deployed, _we could work on deploying it_. We could use the energy that this WG would direct into standardizing some additional techniques, and direct that instead at deployment. All of that said, I want to be clear of two things. First, my personal reaction to any proposal that I suspect someone is going to use is to publish an RFC for it, just because I think it better that it be well documented somewhere and that different implementations do the technique in the same way. Second, even if I thought something were a really bad idea, if the WG expressed a clear preference for that same idea I would regard it as my duty to attempt to push it along the appropriate IETF process (I'm aware that that's not strictly speaking a duty WG chairs have -- it's just my approach to the task). As a WG chair, it's also my duty to try to make sure the output of the WG has some sort of coherence. We decided that DNSSEC was done, and we sent it out. If we think it's either broken or undeployable, we surely have a duty to do something about that. The corollary, I think, is that if we _don't_ think it's broken or undeployable, we have an obligation to future users and deployers of the protocol not to lard it with so many alternative security mechanisms that interoperation is hard to achieve. Best regards, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. -- to unsubscribe send a message to namedroppers-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 Apr 27 07:14:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339E628C10B; Mon, 27 Apr 2009 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 i0mDz7hIYNOV; Mon, 27 Apr 2009 07:14:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51D803A6D97; Mon, 27 Apr 2009 07:14:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyRYd-000Ktn-DX for namedroppers-data0@psg.com; Mon, 27 Apr 2009 14:11:43 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyRYQ-000Ks7-Q0 for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 14:11:36 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 4BB87A1017; Mon, 27 Apr 2009 14:11:25 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "Antoin Verschuren" cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] we need an IAB statement on Secure DNS In-Reply-To: Your message of "Mon, 27 Apr 2009 12:50:24 +0200." <850A39016FA57A4887C0AA3C8085F949C4F3F6@KAEVS1.SIDN.local> References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> <20090424205118.GN70585@shinkuro.com> <850A39016FA57A4887C0AA3C8085F949C4F3F6@KAEVS1.SIDN.local> X-Mailer: MH-E 8.1; nil; GNU Emacs 22.2.1 Date: Mon, 27 Apr 2009 14:11:25 +0000 Message-ID: <76865.1240841485@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > ... > Let's make it an efficient as possible protocol. > > Antoin Verschuren while i agree with this, i am even more concerned about complexity than on inefficiency. more state, more flux, at global scale, for not just the current size of the internet but for the size several decades from 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 Apr 27 08:17:12 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10ADB3A6900; Mon, 27 Apr 2009 08:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.372 X-Spam-Level: *** X-Spam-Status: No, score=3.372 tagged_above=-999 required=5 tests=[AWL=-1.678, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, MIME_ASCII0=1.5, 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 VWKDNuTS7rzw; Mon, 27 Apr 2009 08:17:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 901843A685D; Mon, 27 Apr 2009 08:17:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LySWL-0000ne-Nr for namedroppers-data0@psg.com; Mon, 27 Apr 2009 15:13:25 +0000 Received: from [94.198.152.69] (helo=arn1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LySW7-0000lh-0l for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 15:13:17 +0000 Received: from sidn.nl ([192.168.2.12]) by arn1-kamx.sidn.nl with ESMTP id n3RFD7sl025240 for ; Mon, 27 Apr 2009 17:13:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [dnsext] we need an IAB statement on Secure DNS Date: Mon, 27 Apr 2009 17:13:35 +0200 Message-ID: <850A39016FA57A4887C0AA3C8085F949C4F45E@KAEVS1.SIDN.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dnsext] we need an IAB statement on Secure DNS Thread-Index: AcnHPtKiRal2cX+nTAOwdnomoa/kjwAAdTOA References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> <20090424205118.GN70585@shinkuro.com> <850A39016FA57A4887C0AA3C8085F949C4F3F6@KAEVS1.SIDN.local> <20090427130522.GS9502@burnout.tpb.net> From: "Antoin Verschuren" To: "Niels Bakker" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3duZXItbmFtZWRyb3BwZXJzQG9wcy5p ZXRmLm9yZyBbbWFpbHRvOm93bmVyLQ0KPiBTdWJqZWN0OiBSZTogW2Ruc2V4dF0gd2UgbmVlZCBh biBJQUIgc3RhdGVtZW50IG9uIFNlY3VyZSBETlMNCj4gDQo+IFlvdXIgZmlsdGVyIGlzIGNsZWFy bHkgb3BlcmF0aW5nIHdheSBhYm92ZSBhbmQgYmV5b25kIHRoZSB0ZWNobmljYWwuDQo+IEFkanVz dGluZyBpdCB0byBpbmNyZW1lbnRhbCBpbXByb3ZlbWVudHMgaW4gdGhlIEROUyBwcm90b2NvbCBz ZWVtcyBvbmx5DQo+IGZhaXIgaW4gbXkgZXllcy4gIChJIGNhbiBvbmx5IGFzc3VtZSBETlNTRUMg cXVlcmllcyB3aWxsIHJlcXVpcmUgbXVjaA0KPiBtb3JlIGluLWRlcHRoIGNoYW5nZXMgdG8geW91 ciBJRFMgdG9vbHMuKQ0KDQpJJ20gbW9yZSB0aGFuIHdpbGxpbmcgdG8gYWRkYXB0IHRvIHByb3Rv Y29sIGNoYW5nZXMuDQpJIHdhcyBvbmx5IGdpdmluZyBhbiBleGFtcGxlIHRvIHRoZSBzdGF0ZW1l bnQgdGhhdCBFRE5TMCBQaW5nIGRpZG4ndCBpbXBhY3Qgb3BlcmF0aW9ucy4NCkkgdGhpbmsgaXQg ZG9lcy4gRXZlcnkgcHJvdG9jb2wgYWRqdXN0bWVudCBkb2VzLg0KSG93IG15IGFsZ29yaXRobSB3 b3JrcyBpbiB0aGlzIGV4YW1wbGUgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRpc2N1c3Npb24g SSB0aGluay4NCg0KPiBUaGF0J3MgZ29vZC4gIE11Y2ggaW4gdGhlIHNhbWUgdmVpbiwgSSBhc3N1 bWUgeW91ciBzZXJ2ZXJzIGFyZSBhbHJlYWR5DQo+IGhhbmRsaW5nIHRoZSBleHRyYSB0cmFmZmlj IGZvciBlLmcuIEFBQUEgcXVlcmllcyBmaW5lLg0KDQpZZXMsIGFuZCB3aWxsaW5nIHRvIGFjY2Vw dCBleHRyYSBETlNTRUMgdHJhZmZpYyBhcyB3ZWxsIGFzIGxvbmcgYXMgaXQgZm9sbG93cyB0aGUg cHJvdG9jb2wgYW5kIHB1cnBvc2Ugb2YgRE5TLg0KQnV0IG5vdCB3aWxsaW5nIHRvIGFjY2VwdCBz b21lIDUwLjAwMCBxcHMgZnJvbSBhIHNpbmdsZSBpbmRpdmlkdWFsIHVzaW5nIHRoZSBETlMgYXMg YSByYW5kb20gbm9pc2UgZ2VuZXJhdG9yIGJlY2F1c2UgIml0IGNhbiIuIA0KRE5TIGlzIG5vdCBp bnZlbnRlZCBmb3IgdGhhdC4gDQpGaWx0ZXJpbmcgb3V0IHRob3NlIGluZGl2aWR1YWxzIHRvIGtl ZXAgc2VydmluZyB0aGUgcmVzdCBvZiB0aGUgY29tbXVuaXR5IHRoYXQgcmVsaWVzIG9uIHJlc29s dmluZyBpcyBhIGdyb3dpbmcgY2hhbGxlbmdlLg0KDQo+IA0KPiBBcmUgeW91IGFkdm9jYXRpbmcg dG8gbGV0IHNvbWUgYXR0YWNrIHZlY3RvcnMgZ28gdW5hZGRyZXNzZWQ/DQoNCkknbSBhZHZvY2F0 aW5nIGFzIGxpdHRsZSBleHRyYSBjb21wbGV4aXR5IGFzIHBvc3NpYmxlIHRvIGFkZHJlc3MgYWxs IHRoZSBhdHRhY2sgdmVjdG9ycy4NCklmIEROU1NFQyBhZGRyZXNzZXMgYWxsIHRoZSBhdHRhY2sg dmVjdG9ycywgSSB0aGluayB3ZSBzaG91bGQgZ28gZm9yIHRoYXQuDQpJZiB0aGVyZSBhcmUgb3Ro ZXIgZXZlbiBtdWx0aXBsZSBzb2x1dGlvbnMgdGhhdCBhZGRyZXNzIGFsbCB0aGUgYXR0YWNrIHZl Y3RvcnMsIEknbSBoYXBweSB0byBsaXN0ZW4gdG8gdGhlbS4NCkJ1dCBhZGRyZXNzaW5nIG9uZSBh dHRhY2sgdmVjdG9yIG5vdywgb25lIG1vcmUgbmV4dCB5ZWFyLCBhbmQgZW5kaW5nIHVwIHdpdGgg bW9yZSBjb21wbGV4aXR5IGFuZCB0cmFmZmljIHRoYW4gRE5TU0VDIHBsdXMgbm8gZW5kLXRvLWVu ZCB3aXRoIG5vIHR1cm5pbmcgYmFjayBpcyBub3Qgd2hhdCBJIHdpc2ggZm9yLg0KDQo+ID5MZXQn cyBtYWtlIGl0IGFuIGVmZmljaWVudCBhcyBwb3NzaWJsZSBwcm90b2NvbC4NCj4gDQo+IEFuZCB3 aGF0IGFib3V0IHRoZSBwZW9wbGUgd2hvIGF0dGFjaCBUVExzIGxvd2VyIHRoYW4gd2hhdCBTSURO IHB1Ymxpc2hlcw0KPiBpbiB0aGUgLm5sIHpvbmUgdG8gdGhlaXIgTlMgcmVjb3JkcyByZXR1cm5l ZCB3aXRoIGdsdWU/ICBUaGV5IGNhdXNlDQo+IG1vcmUgdHJhZmZpYyBvbiBjY1RMRCBzZXJ2ZXJz IHRoYW4gdGhleSBvdGhlcndpc2Ugd291bGQgaGF2ZSBnb3R0ZW4uDQo+IEFyZSB5b3Ugd2lsbGlu ZyB0byB0YWtlIGFzIHZvY2FsIGEgc3RhbmQgYWdhaW5zdCB0aGF0IHByYWN0aWNlPw0KDQpJIHRo aW5rIHRoYXQgcHJhY3RpY2UgaXMgYm90aCBzdHVwaWQgYW5kIHllcywgd2UgZG8gdGFrZSBhIHZv Y2FsIHN0YW5kLg0KSXQncyBldmVuIGluIG91ciBsb2NhbCBwb2xpY3kuDQpXZSBoYXZlIHJlc3Ry aWN0aW9ucyBvbiBUVEwgdmFsdWVzIG9mIE5TIFJSc2V0cyBhbmQgYXJlIGNoZWNraW5nIHRoZW0g cmVndWxhcmx5LCBhbmQgd2FybmluZyByZWdpc3RyYXJzIGJ5IHNlbmRpbmcgdGhlbSBhIG1vbnRo bHkgcmVwb3J0Lg0KQW5kIGFzIGZvciB0aGUgc3R1cGlkOiBXZSBoYWQgYW4gaW5jaWRlbnQgYWJv dXQgYSB5ZWFyIGFnbyB3aGVyZSB0aGUgY2FsY3VsYXRpb24gb2YgZ2x1ZSBpbiBvdXIgcmVnaXN0 cnkgc3lzdGVtIG1lc3NlZCB1cC4NClRoZSBzaXR1YXRpb24gd2FzIGNvcnJlY3RlZCBidXQgdGhl cmUgd2FzIHNvbWUgbWlzc2luZyBnbHVlIGR1cmluZyB0aGUgcHVibGljYXRpb24gb2Ygb3VyIHpv bmUgZmlsZSBmb3Igc29tZSBob3Vycy4NCk1vc3Qgb2YgdGhlIHpvbmVzIGtlcHQgd29ya2luZyBm aW5lLCBidXQgc29tZSBETlMgcHJvdmlkZXJzIHRoYXQgaGFkIHRvbyBsb3cgVFRMJ3Mgb24gdGhl aXIgTlMgc2V0cyAoc29tZSBhcyBsb3cgYXMgNSBzZWNvbmRzKSB2YW5pc2hlZCBmcm9tIHRoZSBl YXJ0aCB1bnRpbCB0aGUgbmV4dCB6b25lZmlsZSBwdWJsaWNhdGlvbiAyIGhvdXJzIGxhdGVyLiBJ IGFkbWl0IHdlIHNob3VsZG4ndCBoYXZlIG1hZGUgdGhlIGVycm9yIGluIHRoZSBmaXJzdCBwbGFj ZSwgYnV0IGl0IHByb3ZlZCB3aHkgd2UgYWR2b2NhdGUgcHJvcGVyIFRUTCdzLiBJdCBtYWtlcyB0 aGUgRE5TIG1vcmUgcm9idXN0IHRvIG9wZXJhdGlvbmFsIGVycm9ycyB0aGF0IGRvIGhhcHBlbi4g SSB0aGluayB0aGF0IHRoZSBvcGVyYXRvcnMgdGhhdCB3ZXJlIGFmZmVjdGVkIHJlYWxpemVkIHRo YXQgYWZ0ZXJ3YXJkcyBhcyB3ZWxsLg0KQW5kIHRoYXQgaXMgZXhhY3RseSB3aHkgSSBkb24ndCB3 YW50IHRoZSBwcm90b2NvbCB0byBiZWNvbWUgc28gY29tcGxleCB0aGF0IGF2ZXJhZ2Ugb3BlcmF0 b3JzIGRvbid0IHVuZGVyc3RhbmQgaXQgYW55bW9yZS4NCg0KQnV0IEkgZmFpbCB0byBzZWUgd2hh dCB0aGF0IGhhcyB0byBkbyB3aXRoIHRoaXMgZGlzY3Vzc2lvbi4gDQpUaGUgcHJvdG9jb2wgY2xl YXJseSBzdGF0ZXMgVFRMJ3Mgc2hvdWxkIGJlIGNob3NlbiBjYXJlZnVsbHkgYmVjYXVzZSBpdCBy ZWFsaXplcyBpdCBhZmZlY3RzIHF1ZXJ5IGxvYWQgYW5kIHJvYnVzdG5lc3MuDQoNCkFudG9pbiBW ZXJzY2h1cmVuDQoNClRlY2huaWNhbCBQb2xpY3kgQWR2aXNvcg0KU0lETg0KVXRyZWNodHNld2Vn IDMxMA0KUE8gQm94IDUwMjINCjY4MDIgRUEgQXJuaGVtDQpUaGUgTmV0aGVybGFuZHMNCg0KVCAr MzEgMjYgMzUyNTUwMA0KRiArMzEgMjYgMzUyNTUwNQ0KTSArMzEgNiAyMzM2ODk3MA0KRSBhbnRv aW4udmVyc2NodXJlbkBzaWRuLm5sDQpXIGh0dHA6Ly93d3cuc2lkbi5ubC8NCg0KDQotLS0tLUJF R0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogOS42LjMgKEJ1aWxkIDMwMTcpDQoNCndz QlZBd1VCU2ZYTG56cUhyTTg4M0FnbkFRaDFlQWdBeEVJcUp6aWF2ZnRlR2VGeFdSeGxFS1NlRGFM dVllUUoNCldvR1o3VUhndm9RLytycjBqTWxzN1FzVHZsNEVqYit2UnZiaVJNOWVOMm5pWURnbVEy eEJSTFpib1FnMXFZSGoNCmxvdHpXVUhaQ3NodDlKOGxrdVAvblB0RExLQnhSUjFZMmVXems1Z09Y aE1mdTQwZzFFc2srdkhxQzVyS3hWcXINCktZOHlRRjMyQzBtSWNPdS9xQVVwU1gyQWtEZFFod1h3 QjRTZWtuUFI5SW9ZbGpHQ0lUQmFOY2FoYjd6TGhGakMNClRXbTV2M2RNODJvS21Id1FyQ2xmMEx3 SCsvbGVyMjh2TFV3UFNDdXAyOGZLelZGdTBEdHQrdFFKWnpCVUtPU0YNCnlnVjlxRWZMZ2lycjV2 Ty9UaEkwblhMRHdSUjZtbjVJVFhVNW5Pc1d4aDRqbTJZOVJ2blhDdz09DQo9cG9MSQ0KLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg== -- to unsubscribe send a message to namedroppers-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 Apr 27 09:06:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930BE28C16D; Mon, 27 Apr 2009 09:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.314 X-Spam-Level: X-Spam-Status: No, score=-5.314 tagged_above=-999 required=5 tests=[AWL=-0.266, 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 c3M6rGYN6ixb; Mon, 27 Apr 2009 09:06:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B40D28C177; Mon, 27 Apr 2009 09:06:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyTHd-0004kX-TW for namedroppers-data0@psg.com; Mon, 27 Apr 2009 16:02:17 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyTHR-0004jY-Dw for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 16:02:11 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n3RG1e8E006791; Mon, 27 Apr 2009 09:01:40 -0700 (PDT) Cc: Nicholas Weaver , "Niels Bakker" , Message-Id: <6595A6A5-4B3D-4997-99D9-78108CCB318D@icsi.berkeley.edu> From: Nicholas Weaver To: "Antoin Verschuren" In-Reply-To: <850A39016FA57A4887C0AA3C8085F949C4F45E@KAEVS1.SIDN.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] we need an IAB statement on Secure DNS Date: Mon, 27 Apr 2009 09:01:40 -0700 References: <20090423160510.6e5ef40f8e26486419d141b74a9c894d.d4c86d567f.wbe@email.secureserver.net> <20090424174852.GL70585@shinkuro.com> <20090424182253.GA9779@vacation.karoshi.com.> <20090424205118.GN70585@shinkuro.com> <850A39016FA57A4887C0AA3C8085F949C4F3F6@KAEVS1.SIDN.local> <20090427130522.GS9502@burnout.tpb.net> <850A39016FA57A4887C0AA3C8085F949C4F45E@KAEVS1.SIDN.local> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 27, 2009, at 8:13 AM, Antoin Verschuren wrote: >> Are you advocating to let some attack vectors go unaddressed? > > I'm advocating as little extra complexity as possible to address all > the attack vectors. > If DNSSEC addresses all the attack vectors, I think we should go for > that. > If there are other even multiple solutions that address all the > attack vectors, I'm happy to listen to them. > But addressing one attack vector now, one more next year, and ending > up with more complexity and traffic than DNSSEC plus no end-to-end > with no turning back is not what I wish for. Except were not talking about that. An attacker can be either in-path (see the packets) or out-of-path (not see the packets). Period. The question is: What level of protection should there be for transactions and caches for out-of-path attackers? and Should the presence but lack of deployment of DNSSEC preclude the development and deployment of solutions against out of path attackers? With sufficient query entropy (48+bits in practice), out of path attackers are killed completely, so there is an end-state to out-of- path attackers. Or with decent entropy (32-36 bits) combined with glue policy changes, out of path attacks on the cache become impractical because they take too much time, rather than too many packets. You could still do out- of-path transaction attacks, but those are far less useful. [1] These are end state conditions, and if we are willing to deploy the changes to reach these end states, nothing else should need to be done against out-of-path attackers. While any defense against in-path attackers requires DNSSEC or something that is effectively equivalent in terms of deployment costs (maintaining cryptographic relationships across the delegation path for every name). Thus this is not "one attack vector now, one more next year, one more after that..." Its there are only two possible attack classes: in- path or out-of-path. [1] This is pretty much the situation with Unbound with 0x20 turned on, since unbound has the paranoid glue-policy policy which eliminates "race until win", and with 0x20 this gets to about 36-40 bits of entropy per query in practice. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From morrisonm@alsopreview.com Mon Apr 27 09:38:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC183A6874 for ; Mon, 27 Apr 2009 09:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.38 X-Spam-Level: X-Spam-Status: No, score=-9.38 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 t8LWkl+ZHNL9 for ; Mon, 27 Apr 2009 09:38:17 -0700 (PDT) Received: from amag-inc.com (unknown [189.135.92.138]) by core3.amsl.com (Postfix) with SMTP id ABC743A6B5D for ; Mon, 27 Apr 2009 09:38:13 -0700 (PDT) To: " Date: Mon, 27 Apr 2009 09:38:13 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Mon Apr 27 09:51:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85793A6C35; Mon, 27 Apr 2009 09:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=0.281, 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 QmeCIOFRy9cG; Mon, 27 Apr 2009 09:51:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7ED503A69C5; Mon, 27 Apr 2009 09:50:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyTyc-0009sr-0P for namedroppers-data0@psg.com; Mon, 27 Apr 2009 16:46:42 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyTyJ-0009rX-Qe for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 16:46:35 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A66D53A6F7A; Mon, 27 Apr 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090427164501.A66D53A6F7A@core3.amsl.com> Date: Mon, 27 Apr 2009 09:45: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-02.txt Pages : 6 Date : 2009-04-27 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-27093832.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 dnspetter@aol.com Mon Apr 27 11:15:24 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9223A69F0 for ; Mon, 27 Apr 2009 11:15:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: SALE 77% OFF on VIAGRA\256 \n X-Spam-Flag: NO X-Spam-Score: -8.763 X-Spam-Level: X-Spam-Status: No, score=-8.763 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_DYNAMIC_CHELLO_NL=3.595, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 oCunfmqd+Abf for ; Mon, 27 Apr 2009 11:15:18 -0700 (PDT) Received: from a55032.upc-a.chello.nl (a55032.upc-a.chello.nl [62.163.55.32]) by core3.amsl.com (Postfix) with SMTP id 6F2A53A6B01 for ; Mon, 27 Apr 2009 11:15:16 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 4649 by uid 166); Tue, 28 Apr 2009 08:15:34 +0100 Message-Id: <20090428091534.4651.qmail@a55032.upc-a.chello.nl> To: Subject: SALE 77% OFF on VIAGRA® From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 27 Apr 2009 11:15:16 -0700 (PDT) Bernat® Newsletter - Spring 2009

This e-mail was sent to you by Pharmacy®. You are receiving this email because you have subscribed to the Viagra® newsletter with the following address: dnsext-archive@ietf.org.

View Web Version || Privacy policy | Contact us
Member's Newsletter
Summer 2008
Satisfaction Guaranteed - Our Company wants you to be absolutely satisfied with your pharmacy.
If, within 30 days of receiving your purchase you're not completely
satisfied, return it for the price you paid or we will gladly replace it.

Web Exclusive Satin Lace Cardigan

Buy Online

You are receiving this email because you have subscribed to the Pharmacy® newsletter with the following address: dnsext-archive@ietf.org.

Unsubscribe | Privacy policy | Contact us

© 2008 Pharmacy All rights reserved.
From owner-namedroppers@ops.ietf.org Mon Apr 27 13:45:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2283A6835; Mon, 27 Apr 2009 13:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-0.415, 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 apCt3Dj4JKkL; Mon, 27 Apr 2009 13:45:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 714C33A7007; Mon, 27 Apr 2009 13:45:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyXXf-0002yU-Eq for namedroppers-data0@psg.com; Mon, 27 Apr 2009 20:35:07 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyXXM-0002wZ-Mq for namedroppers@ops.ietf.org; Mon, 27 Apr 2009 20:35:00 +0000 Received: from [192.168.1.103] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3RKYgow008021; Mon, 27 Apr 2009 16:34:43 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090427164501.A66D53A6F7A@core3.amsl.com> References: <20090427164501.A66D53A6F7A@core3.amsl.com> Date: Mon, 27 Apr 2009 16:34:39 -0400 To: Internet-Drafts@ietf.org From: Edward Lewis Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-02.txt Cc: i-d-announce@ietf.org, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: At 9:45 -0700 4/27/09, Internet-Drafts@ietf.org wrote: >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-md5-deprecated-02.txt > Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records > draft-ietf-dnsext-tsig-md5-deprecated-02.txt >Abstract > > 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). The purpose of this document is to change the IANA registry for TSIG Algorithm Names to deprecate the use of HMAC-MD5 as working keyed hash algorithm for the TSIG and TKEY methods of providing DNS message integrity protection. > >1. Introduction > > The secret key transaction authentication for DNS (TSIG, [RFC2845]) > was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm. As > the MD5 [RFC1321] security was recognized to be lower than expected, > [RFC4635] standardized new TSIG algorithms based on SHA > [RFC3174][RFC3874][RFC4634] digests. "lower than expected" -> this should be reworded. Also the verb tenses I think are off - The secret key transaction authentication for DNS (TSIG, [RFC2845]) has been defined with the HMAC-MD5 [RFC2104] cryptographic algorithm. When MD5 [RFC1321] security came to be considered obsolete [reference?], [RFC4635] standardized new TSIG Algorithms Names based on SHA [RFC3174][RFC3874][RFC4634] digests. > > But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This > document is targeted to complete the process, in details: "in detail" (drop the 's')" > 1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm > name registry managed by the IANA under the IETF Review Policy > [RFC5226] Can we mark it "historic" instead of "optional?" Or even "deprecated?" >2. Implementation Requirements > > The table of section 3 of [RFC4635] is replaced by: > > +-------------------+--------------------------+ > | Requirement Level | Algorithm Name | > +-------------------+--------------------------+ > | Optional | HMAC-MD5.SIG-ALG.REG.INT | "Deprecated"? >4. IANA Consideration > > This document extends the "TSIG Algorithm Names - per [] and > [RFC2845]" located at > http://www.iana.org/assignments/tsig-algorithm-names by adding a new > column to the registry "Compliance Requirement". > > The registry should contain the following: > > +--------------------------+------------------------+-------------+ > | Algorithm Name | Compliance Requirement | Reference | > +--------------------------+------------------------+-------------+ > | gss-tsig | Optional | [RFC3645] | > | HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] | Deprecated/Historic? >5. Availability Considerations > > MD5 is no more universally available and its use should lead to > increasing operation issues. SHA1 is likely to suffer from the same > kind of problem. To summary MD5 has reached end-of-life and SHA1 > follows few years behind. Do you mean "MD5 is no longer universally available"? And SHA1 "is [eventually?} likely to suffer" - any time soon? This doc title is about HMAC-MD5, not SHA1. >6. Security Considerations > > This document does not assume anything about the cryptographic > security of different hash algorithms. It is a routine maintenance, > its goal is better availability of some security mechanisms in a > predictable future. That's okay for HMAC-MD5 if there is a reference to a statement it is obsolete, but not so for SHA1 (yet). I'd drop any change to SHA1 for now and add pointers to HMAC analysis to support this assertion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy if you don't want much. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From mario54532@aim.com Mon Apr 27 14:19:29 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D400A28C1D0 for ; Mon, 27 Apr 2009 14:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.845 X-Spam-Level: X-Spam-Status: No, score=-6.845 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HELO_MISMATCH_RU=3.1, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 Be0aWePdEZDA for ; Mon, 27 Apr 2009 14:19:29 -0700 (PDT) Received: from r190-134-214-34.dialup.adsl.anteldata.net.uy (r190-134-214-34.dialup.adsl.anteldata.net.uy [190.134.214.34]) by core3.amsl.com (Postfix) with SMTP id 626B53A6A32 for ; Mon, 27 Apr 2009 14:19:20 -0700 (PDT) To: " Date: Mon, 27 Apr 2009 14:19:20 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From testis@fiducafe.com.co Mon Apr 27 17:23:32 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D043E3A696E for ; Mon, 27 Apr 2009 17:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.121 X-Spam-Level: ** X-Spam-Status: No, score=2.121 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=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 68glwklB4bb1 for ; Mon, 27 Apr 2009 17:23:32 -0700 (PDT) Received: from eqxdalb.vodafone.de (ip-77-24-45-227.web.vodafone.de [77.24.45.227]) by core3.amsl.com (Postfix) with SMTP id A86CC3A6A56 for ; Mon, 27 Apr 2009 17:23:30 -0700 (PDT) Message-ID: <2949343827.20090428002019@fiducafe.com.co> Date: Tue, 28 Apr 2009 00:24:37 +0000 From: Esshaki Vagliardo User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: dnsext-archive@lists.ietf.org Subject: census eexclamatory grayish gauged Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit sync wharfmaaster antipathizes coxswain From kinnou@amada.co.jp Tue Apr 28 01:38:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C074B3A6966 for ; Tue, 28 Apr 2009 01:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.972 X-Spam-Level: X-Spam-Status: No, score=-10.972 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 iOIEw5np8Qrh for ; Tue, 28 Apr 2009 01:37:54 -0700 (PDT) Received: from alpin-ballooning.de (unknown [124.123.232.234]) by core3.amsl.com (Postfix) with SMTP id 26A0D3A67EB for ; Tue, 28 Apr 2009 01:37:51 -0700 (PDT) To: " Date: Tue, 28 Apr 2009 01:37:51 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From dnshhy@aol.com Tue Apr 28 05:00:18 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C923A6C12 for ; Tue, 28 Apr 2009 05:00:18 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -67.12 X-Spam-Level: X-Spam-Status: No, score=-67.12 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, IMPOTENCE=1.886, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_BLACK=20, 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 XHOOLzqxIhZE for ; Tue, 28 Apr 2009 05:00:11 -0700 (PDT) Received: from amerblind.outbound.ed10.com (rrcs-24-199-163-238.midsouth.biz.rr.com [24.199.163.238]) by core3.amsl.com (Postfix) with SMTP id EB9A73A70A5 for ; Tue, 28 Apr 2009 05:00:10 -0700 (PDT) X-Originating-IP: [75.063.798.2] X-Originating-Email: [dnsext-archive@ietf.org] X-Sender: dnsext-archive@ietf.org To: Subject: RE: Pharmacy Message RT.2111 From: VIAGRA ® Official Site MIME-Version: 1.0 Importance: High Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20090428120010.EB9A73A70A5@core3.amsl.com> Date: Tue, 28 Apr 2009 05:00:10 -0700 (PDT) Sleep Well Newsletter

WebMD Newsletter


WebMD Privacy Policy
WebMD Office of Privacy
1175 Peachtree Street, Suite 2400, Atlanta, GA 30361
© 2008 WebMD, LLC. All rights reserved.

From kristien.spruyt@accent.be Tue Apr 28 05:11:26 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABDC28C1E2 for ; Tue, 28 Apr 2009 05:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_BROADBND=1.118, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HELO_EQ_DSL_3=1.022, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 LEuHSmhVY0Dz for ; Tue, 28 Apr 2009 05:11:19 -0700 (PDT) Received: from dsl-sp-81-140-52-47.in-addr.broadbandscope.com (dsl-sp-81-140-52-47.in-addr.broadbandscope.com [81.140.52.47]) by core3.amsl.com (Postfix) with SMTP id D694C3A6C5A for ; Tue, 28 Apr 2009 05:11:10 -0700 (PDT) To: " Date: Tue, 28 Apr 2009 05:11:10 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Tue Apr 28 12:57:09 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0773A6CFD; Tue, 28 Apr 2009 12:57:09 -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 dA1TIS9AoTJj; Tue, 28 Apr 2009 12:56:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2314F3A6C96; Tue, 28 Apr 2009 12:56:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LytJ0-0005j8-9M for namedroppers-data0@psg.com; Tue, 28 Apr 2009 19:49:26 +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 1LytIm-0005hq-LH for namedroppers@ops.ietf.org; Tue, 28 Apr 2009 19:49:18 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n3SJnABA051319; Tue, 28 Apr 2009 21:49:10 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200904281949.n3SJnABA051319@givry.fdupont.fr> From: Francis Dupont To: bert hubert cc: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] Request for adoption of draft-hubert-ulevitch-edns-ping.txt as a working group document In-reply-to: Your message of Mon, 20 Apr 2009 22:31:30 +0200. <3efd34cc0904201331s32f7882bv95119df436829a03@mail.gmail.com> Date: Tue, 28 Apr 2009 21:49:10 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: We therefore hope you will support draft-hubert-ulevitch-edns-ping.txt as a working group document. => I am slightly against the adoption of the document as a WG item: - its security benefits are limited to hop-by-hop without on path attackers (note we already have standard unrestricted hop-by-hop protection with TSIG and SIG(0), and end-to-end with DNSSEC) - so it can be only a very partial to the forgery resilience issue - it does not provide by itself a way to force a response from a server (i.e., the "ping" function) - the option size is between 4 and 16 bytes so it does not provide a way to verify proper transmission with various sizes - so its only real function is the security one... Regards 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 Apr 28 12:57:41 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360AF3A713B; Tue, 28 Apr 2009 12:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.424 X-Spam-Level: X-Spam-Status: No, score=-104.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Ru8xVmO+I83p; Tue, 28 Apr 2009 12:56:38 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id B9A283A69DA; Tue, 28 Apr 2009 12:56:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LytLY-0005ya-M2 for namedroppers-data0@psg.com; Tue, 28 Apr 2009 19:52:04 +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 1LytLL-0005xc-A1 for namedroppers@ops.ietf.org; Tue, 28 Apr 2009 19:51:58 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n3SJphEs051342; Tue, 28 Apr 2009 21:51:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200904281951.n3SJphEs051342@givry.fdupont.fr> From: Francis Dupont To: Stephane Bortzmeyer cc: Paul Vixie , bert hubert , "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-reply-to: Your message of Tue, 21 Apr 2009 09:40:08 +0200. <20090421074008.GA11045@nic.fr> Date: Tue, 28 Apr 2009 21:51:43 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: With this reasoning, DNSSEC is doomed as well, because many middleboxes, firewalls, load balancers, etc, have problems with DNSSEC, too. => these problems are with EDNS, not DNSSEC, so unfortunately are shared at least with EDNS-PING... 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 Apr 28 13:04:05 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55063A6D1F; Tue, 28 Apr 2009 13:04:05 -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 Jk3v-PWqOe9l; Tue, 28 Apr 2009 13:04:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEB813A6E1E; Tue, 28 Apr 2009 13:04:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LytTH-0006ak-U9 for namedroppers-data0@psg.com; Tue, 28 Apr 2009 20:00:03 +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 1LytT3-0006Z2-MS for namedroppers@ops.ietf.org; Tue, 28 Apr 2009 19:59:57 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n3SJxhGD051395; Tue, 28 Apr 2009 21:59:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200904281959.n3SJxhGD051395@givry.fdupont.fr> From: Francis Dupont To: Stephane Bortzmeyer cc: Edward Lewis , "namedroppers@ops.ietf.org" Subject: Re: EDNS ping mechanisms (was [dnsext] Re: Request for adoption ) In-reply-to: Your message of Tue, 21 Apr 2009 09:46:55 +0200. <20090421074655.GB11045@nic.fr> Date: Tue, 28 Apr 2009 21:59:43 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Well, EDNS-ping protects the channel, not the data. It is not a direct competitor of DNSSEC, rather an extension to RFC 5452. => it is channel (aka hop-by-hop) protection against off path attackers, so I agree it doesn't provide something different than RFC 5452 Now, we could discuss for years whether channel protection is better than data protection or vice-versa. => I disagree: the current DNS model is based on the use of recursive/ caching servers so either we change the model (*) or we adopt data (aka end-to-end) protection. Regards Francis.Dupont@fdupont.fr PS: (*) caching/recursive servers are needed to solve transport issues, with the future deployment of IPv6 it could be a very bad idea to ban them by changing the DNS model. -- to unsubscribe send a message to namedroppers-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 Apr 28 13:38:14 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFC33A6C21; Tue, 28 Apr 2009 13:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[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 oAwdaEqQGIVp; Tue, 28 Apr 2009 13:38:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 842323A67EA; Tue, 28 Apr 2009 13:38:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lyu0O-0009TM-Nk for namedroppers-data0@psg.com; Tue, 28 Apr 2009 20:34:16 +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 1Lyu09-0009Rj-CE for namedroppers@ops.ietf.org; Tue, 28 Apr 2009 20:34:08 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n3SKWaMm051576; Tue, 28 Apr 2009 22:32:37 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200904282032.n3SKWaMm051576@givry.fdupont.fr> From: Francis Dupont To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT chair cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? In-reply-to: Your message of Wed, 22 Apr 2009 11:07:09 EDT. <200904221507.n3MF7G6J047453@stora.ogud.com> Date: Tue, 28 Apr 2009 22:32:36 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: Q1: Is ENDS0 Ping more expensive [1] than other EDNS0 options ? => no [1] Q2: Does ENDS0 Ping offer additional protection to "Pre-DNSSEC DNS" OR "both DNSSEC and Pre-DNSSEC" ? => only a very limited protection for pre-DNSSEC. Q3: Are the benefits of ENDS0 Ping realized incrementally with deployment or only when the majority of code bases are deployed? => incrementally Q3.5: Is ENDS Ping more beneficial to the consumer of DNS data or the producer? => consumer Q4: Will ENDS0 Ping delay/prevent DNSSEC deployment? (explain) => no (the main operation issue with DNSSEC comes from EDNS so EDNS-PING has the same) Q5: Does ENDS0 Ping expose any new security risks? => no Q6: Do you support that the WG adopt the document ? If your answer is NO is there any other mechanism you want considered ? Yes assumes you are willing to review future versions of the document. => no (we have no choice other than deploy DNSSEC). BTW I am willing to review future versions of the document (IMHO it is not a bad idea, it just does not provide a complete/efficient enough solution). Regards Francis.Dupont@fdupont.fr PS [1]: I assume the unpredictability is well understood and will be correctly implemented when I got proofs of the opposite... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From mruddy@anbbank.com Tue Apr 28 13:41:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5AD28C21A for ; Tue, 28 Apr 2009 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 7emIsZ6byvos for ; Tue, 28 Apr 2009 13:41:41 -0700 (PDT) Received: from 93-38-50-121.ip69.fastwebnet.it (93-38-50-121.ip69.fastwebnet.it [93.38.50.121]) by core3.amsl.com (Postfix) with SMTP id 00F5028C0E0 for ; Tue, 28 Apr 2009 13:41:34 -0700 (PDT) To: " Date: Tue, 28 Apr 2009 13:41:34 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Tue Apr 28 18:50:22 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91563A6BE9; Tue, 28 Apr 2009 18:50:22 -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 rE+WfSpgV3Yu; Tue, 28 Apr 2009 18:50:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09D5D3A6862; Tue, 28 Apr 2009 18:50:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LyyqF-0004nl-1h for namedroppers-data0@psg.com; Wed, 29 Apr 2009 01:44:07 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lyyq0-0004mo-98 for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 01:43:59 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id ECA57E601C; Wed, 29 Apr 2009 01:41:52 +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.3/8.14.3) with ESMTP id n3T1hmUG097300; Wed, 29 Apr 2009 11:43:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200904290143.n3T1hmUG097300@drugs.dv.isc.org> To: Ted Lemon Cc: Namedroppers WG From: Mark Andrews Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? In-reply-to: Your message of "Sat, 25 Apr 2009 11:20:17 EST." <6E321631-924C-4B73-9017-A2F8AFC315AC@fugue.com> Date: Wed, 29 Apr 2009 11:43:48 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <6E321631-924C-4B73-9017-A2F8AFC315AC@fugue.com>, Ted Lemon writes: > On Apr 25, 2009, at 2:43 AM, Alex Bligh wrote: > > If / when the hotspot providers cease their stupid games so that at > > least > > when you are paid up and logged on it correctly processes DNSSEC > > (which is quite possible), this would only happen when being > > redirected > > to their logon page. > > From a security perspective, a UI that you habitually bypass is a > disaster. I *hope* nobody implements it like that. It should be > pretty easy to detect a hotspot redirect as a special event and do the > right thing. We should just stop trying to intercept things in hot spots and define a DHCP element that says where to go to register or did AAA do something like that. I never followed AAA in enough detail to know. Yes it will take a few years for it to be wildly deployed but it is better than the stupid tricks being tried today which break lots of things. 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 jeffr@activeinfosystems.com Tue Apr 28 20:27:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06343A6D02 for ; Tue, 28 Apr 2009 20:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 lSJ6XySMlMR2 for ; Tue, 28 Apr 2009 20:27:42 -0700 (PDT) Received: from pool-71-165-161-168.lsanca.fios.verizon.net (pool-71-165-161-168.lsanca.fios.verizon.net [71.165.161.168]) by core3.amsl.com (Postfix) with SMTP id DC4183A6C68 for ; Tue, 28 Apr 2009 20:27:41 -0700 (PDT) To: " Date: Tue, 28 Apr 2009 20:27:41 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From jkillah@agora.bungi.com Tue Apr 28 23:44:34 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2743A6D86 for ; Tue, 28 Apr 2009 23:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.817 X-Spam-Level: **** X-Spam-Status: No, score=4.817 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 usGgZnT-wZuh for ; Tue, 28 Apr 2009 23:44:26 -0700 (PDT) Received: from 201-1-169-64.dsl.telesp.net.br (201-1-169-64.dsl.telesp.net.br [201.1.169.64]) by core3.amsl.com (Postfix) with SMTP id 58E253A689C for ; Tue, 28 Apr 2009 23:44:22 -0700 (PDT) To: dnsext-archive@ietf.org Subject: from dnsext-archive@ietf.org From: dnsext-archive@ietf.org MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090429064423.58E253A689C@core3.amsl.com> Date: Tue, 28 Apr 2009 23:44:22 -0700 (PDT)
Tell a friend · Download latest version See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

Ottho Heldringstraat 6, 24305 AZ Amsterdam, The Netherlands
From journalistic044@akc-web.de Wed Apr 29 03:01:15 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84923A70C0 for ; Wed, 29 Apr 2009 03:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 oiKJ6MdH6WW3 for ; Wed, 29 Apr 2009 03:01:09 -0700 (PDT) Received: from cpe-67-242-121-87.stny.res.rr.com (cpe-67-242-121-87.stny.res.rr.com [67.242.121.87]) by core3.amsl.com (Postfix) with SMTP id 575FC3A702A for ; Wed, 29 Apr 2009 03:00:38 -0700 (PDT) To: " Date: Wed, 29 Apr 2009 03:00:38 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From mceralmeria@alcer.info Wed Apr 29 04:25:01 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A185728C22B for ; Wed, 29 Apr 2009 04:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.38 X-Spam-Level: X-Spam-Status: No, score=-9.38 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 tUvnBHZ6LpYD for ; Wed, 29 Apr 2009 04:24:54 -0700 (PDT) Received: from 3mail.com (unknown [81.214.154.218]) by core3.amsl.com (Postfix) with SMTP id 62D8628C226 for ; Wed, 29 Apr 2009 04:24:51 -0700 (PDT) To: " Date: Wed, 29 Apr 2009 04:24:51 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098
From owner-namedroppers@ops.ietf.org Wed Apr 29 08:16:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B7A3A7163; Wed, 29 Apr 2009 08:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=-0.792, 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 vruU1lNmLki5; Wed, 29 Apr 2009 08:16:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E12128C104; Wed, 29 Apr 2009 08:16:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzBOS-000FbX-1q for namedroppers-data0@psg.com; Wed, 29 Apr 2009 15:08:16 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzBOG-000FZY-6a for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 15:08:09 +0000 Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3TF82Qd024363 for ; Wed, 29 Apr 2009 11:08:02 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200904291508.n3TF82Qd024363@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Apr 2009 11:07:30 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: [dnsext] DNSEXT WG document status Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: As of April 29'th 2009 here is the status of various documents and efforts: No documents at RFC editor. IESG: DNS proxy: passed WGLC and was advanced to the IESG on April 24'th WGLC issued: DNAME-bis: waiting for WG chair to finish summary of WGLC RSA/SHA256: Second WGLC to start soon Other WG documents: DNSSEC-updates: Editors are working on getting a WGLC ready version out AXFR-clarify: Editor has requested WGLC, pending chair review. TSIG-MD5-depreciated: New version posted, LC expected soon. RFC2671bis-ends0: Stalled, working with editor to restart process. Documents requesting adoption: Edns-ping: On going discussion on mailing list. DNSSEC-GOST: On going discussion, IERF Crypto Framework Research Group has been engaged to give us feedback on the algorithms and their suitability for standardization. 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 Wed Apr 29 09:12:36 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E33D3A69BD; Wed, 29 Apr 2009 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, 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 aqmsTHIYXfKM; Wed, 29 Apr 2009 09:12:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 965283A6C7E; Wed, 29 Apr 2009 09:12:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzCJ0-000L7e-VV for namedroppers-data0@psg.com; Wed, 29 Apr 2009 16:06:42 +0000 Received: from [209.85.219.158] (helo=mail-ew0-f158.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzCIm-000L6D-3T for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 16:06:35 +0000 Received: by ewy2 with SMTP id 2so1346096ewy.41 for ; Wed, 29 Apr 2009 09:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=NQPVpM0a5xzRGf/dlooWzK7qvHtXYK8IT4O8rncC8SE=; b=JuV8HOu6aS1xPfSqBOvio5B4zHSiVamWnTRSKl4npoSCq9lDveBtIOY5kKSa1Edd5m gzvNtI510Xhfp1hi8yxZMQ/F/vvb1NjpcghC3aTCFjnqZ5lY/ZQYQ+r76qOmahgWzNw8 ZkxxQCPRb5pl+PY8Qxtw/RuSoeAXo6JIQyLTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=uAdSlbcsg2Gid/nao8gAQxiRc3ndtgMBFhbSgXRFMsfT+RJUX16bQmvXtcOscdRnjR PQ8sRku1Yk/Wb7DLxW5p58Oig5EohfASr4SGm1dcel5XcLHcCGsT7ot3vvg0xg7Xy2qv nHjE+B48QqT/3GoCjGCGJTGIQTpKZJk6KXfTs= Received: by 10.210.127.13 with SMTP id z13mr7767453ebc.68.1241021186690; Wed, 29 Apr 2009 09:06:26 -0700 (PDT) Received: from ?192.168.1.204? ([193.82.161.205]) by mx.google.com with ESMTPS id 17sm1325630ewy.91.2009.04.29.09.06.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 09:06:26 -0700 (PDT) Message-Id: From: John Dickinson To: IETF DNSEXT WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: [dnsext] SEP bit Date: Wed, 29 Apr 2009 17:06:24 +0100 X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Whilst trying to explain the meaning of the SEP bit in a document I am writing I found that RFC4033 says "This document and its two companions obsolete [RFC3757]" However, I can not see where this is done in any of 4033-35. In fact 4033 goes on to say: "Key signing keys are discussed in more detail in [RFC3757]." 4034 says: "Bit 15 of the Flags field is the Secure Entry Point flag, described in [RFC3757]" "and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757])" "This flag is only intended to be a hint to zone signing or debugging software as to the intended use of this DNSKEY record; validators MUST NOT alter their behavior during the signature validation process in any way based on the setting of this bit." which by my reading doesn't seem to contradict 3757. Is RFC3757 really obsolete? RFC 4641(bis) goes on to recommend "In this document, we assume a one- to-one mapping between KSK and SEP keys and we assume the SEP flag to be set on all KSKs." This seems reasonable unless you don't want to use a KSK. Are there scenarios where 4641 is not true? It seems that the SEP bit is in danger of taking on meaning that it does not have. Most signers already call it the KSK flag. I am thinking that 4641bis might want to say something like - The SEP bit may be used locally only to aid signers in deciding what RRSets to sign with a given key. However, when signing it would be better to be explicit about which keys sign which RRSets. It should not be used even between cooperating parties such as a parent and child for indicating which key to use for a DS or as a TA. It should be ignored by all other systems especially validators. John --- John Dickinson http://www.jadickinson.co.uk I am riding from Lands end to John O'Groats to raise money for Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009 -- to unsubscribe send a message to namedroppers-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 Apr 29 12:38:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB693A7190; Wed, 29 Apr 2009 12:38:46 -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 UqDLD5rsnn4k; Wed, 29 Apr 2009 12:38:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD6F53A6B0B; Wed, 29 Apr 2009 12:38:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzFWB-000E7C-SI for namedroppers-data0@psg.com; Wed, 29 Apr 2009 19:32:31 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzFUY-000E0S-0g for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 19:31:14 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n3TJUmqG027428 for ; Wed, 29 Apr 2009 15:30:48 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.3/8.14.3/Submit) id n3TJUm23027427 for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 15:30:48 -0400 (EDT) (envelope-from namedroppers) Received: from [2001:4f8:3:ba:21f:c6ff:fe69:9eea] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lz11f-000Dl1-8w for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 04:04:08 +0000 Received: from [IPv6:2001::53aa:64c:0:2a9b:bcf6:7a2c] (unknown [IPv6:2001:0:53aa:64c:0:2a9b:bcf6:7a2c]) by toccata.fugue.com (Postfix) with ESMTPSA id 7D2FE34E44E1; Tue, 28 Apr 2009 21:04:17 -0700 (MST) Cc: Namedroppers WG Message-Id: From: Ted Lemon To: Mark Andrews In-Reply-To: <200904290143.n3T1hmUG097300@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 v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Tue, 28 Apr 2009 23:04:00 -0500 References: <200904290143.n3T1hmUG097300@drugs.dv.isc.org> X-Mailer: Apple Mail (2.930.3) X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 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. ] On Apr 28, 2009, at 8:43 PM, Mark Andrews wrote: > We should just stop trying to intercept things in hot spots > and define a DHCP element that says where to go to register > or did AAA do something like that. I never followed AAA > in enough detail to know. "We" aren't intercepting DNS in hot spots. I agree that it's the wrong thing to do, but the problem is that it's working, and when things work, it's hard to get the people benefiting from them to do something different, particularly when it requires coordinated deployment. I think probably the guys at FON would be the ones to talk to if we want to do something through DHCP, but the problem is that we have very little to offer them unless Microsoft and Apple are willing to implement the other side of it. Apple doesn't do DHCPv6, so it's going to be kind of hard to make progress there with a DHCPv6 option. So I agree in principle that what you are saying makes sense, but I don't see quite as clear a path forward as the one you suggest. -- to unsubscribe send a message to namedroppers-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 Apr 29 13:09:43 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C553A71A1; Wed, 29 Apr 2009 13:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.537, 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 LQObqJz1YuXL; Wed, 29 Apr 2009 13:09:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C0D093A6D64; Wed, 29 Apr 2009 13:09:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzG1f-000HJY-7F for namedroppers-data0@psg.com; Wed, 29 Apr 2009 20:05:03 +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 1LzG1M-000HHd-4Q for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 20:04:53 +0000 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id lPAs1b00D0mv7h05AY4kix; Wed, 29 Apr 2009 20:04:44 +0000 Received: from MIKES-LAPTOM.comcast.net ([68.48.0.201]) by OMTA11.westchester.pa.mail.comcast.net with comcast id lY4j1b00U4LCBKY3XY4jaa; Wed, 29 Apr 2009 20:04:44 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Apr 2009 16:04:42 -0400 To: John Dickinson , IETF DNSEXT WG From: Michael StJohns Subject: Re: [dnsext] SEP bit 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: Except see RFC5011. Keys with the SEP bit set are the only ones tracked by the key rollover mechanism described there. At 12:06 PM 4/29/2009, John Dickinson wrote: >Whilst trying to explain the meaning of the SEP bit in a document I am >writing I found that > >RFC4033 says "This document and its two companions obsolete >[RFC3757]" > >However, I can not see where this is done in any of 4033-35. > >In fact 4033 goes on to say: > >"Key signing keys are discussed in more detail in [RFC3757]." > >4034 says: >"Bit 15 of the Flags field is the Secure Entry Point flag, described >in [RFC3757]" >"and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757])" >"This flag is only intended to be a hint to zone signing or debugging >software as to the intended use of this DNSKEY record; validators MUST >NOT alter their behavior during the signature validation process in >any way based on the setting of this bit." which by my reading doesn't >seem to contradict 3757. >Is RFC3757 really obsolete? >RFC 4641(bis) goes on to recommend "In this document, we assume a one- to-one mapping between KSK and SEP keys and we assume the SEP flag to >be set on all KSKs." This seems reasonable unless you don't want to >use a KSK. >Are there scenarios where 4641 is not true? It seems that the SEP bit >is in danger of taking on meaning that it does not have. Most signers >already call it the KSK flag. >I am thinking that 4641bis might want to say something like - The SEP >bit may be used locally only to aid signers in deciding what RRSets to >sign with a given key. However, when signing it would be better to be >explicit about which keys sign which RRSets. It should not be used >even between cooperating parties such as a parent and child for >indicating which key to use for a DS or as a TA. It should be ignored >by all other systems especially validators. >John >--- >John Dickinson >http://www.jadickinson.co.uk > >I am riding from Lands end to John O'Groats to raise money for >Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009 > > > > >-- >to 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 Apr 29 15:12:25 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9803A6833; Wed, 29 Apr 2009 15:12:25 -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] 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 QBMIdonL56Ho; Wed, 29 Apr 2009 15:12:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C99313A6A03; Wed, 29 Apr 2009 15:12:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzHwR-0002Jb-SO for namedroppers-data0@psg.com; Wed, 29 Apr 2009 22:07:47 +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 1LzHw9-0002IG-4z for namedroppers@ops.ietf.org; Wed, 29 Apr 2009 22:07:40 +0000 Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id n3TM7RIo058189; Thu, 30 Apr 2009 00:07:27 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200904292207.n3TM7RIo058189@givry.fdupont.fr> From: Francis Dupont To: namedroppers@ops.ietf.org Cc: dnsext-chairs@tools.ietf.org Subject: [dnsext] Re: I-D Action:draft-ietf-dnsext-tsig-md5-deprecated-02.txt In-reply-to: Your message of Mon, 27 Apr 2009 09:45:01 PDT. <20090427164501.A66D53A6F7A@core3.amsl.com> Date: Thu, 30 Apr 2009 00:07:27 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In your previous mail you wrote: => this draft addresses all issues raised, I ask for WGLC... Thanks Francis.Dupont@fdupont.fr 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 Reco rds Author(s) : F. Dupont Filename : draft-ietf-dnsext-tsig-md5-deprecated-02.txt Pages : 6 Date : 2009-04-27 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-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- to unsubscribe send a message to namedroppers-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 Apr 29 17:31:46 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BF63A7077; Wed, 29 Apr 2009 17:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_05=-1.11, 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 Ne-mLr20TOfc; Wed, 29 Apr 2009 17:31:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1C7623A6E9A; Wed, 29 Apr 2009 17:31:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzK5h-000ClK-Fw for namedroppers-data0@psg.com; Thu, 30 Apr 2009 00:25:29 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzK5O-000Cjw-Vb for namedroppers@ops.ietf.org; Thu, 30 Apr 2009 00:25:22 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=DXSXD7V9eY727Ie+vynIMnMuU3ACrk1q5lfJ9cbzaP/QrcFfhD9MIV8LxSgWXm79; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.96.55] (helo=ix.netcom.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzK5E-0004nG-85; Wed, 29 Apr 2009 20:25:01 -0400 Message-ID: <49F8EFCF.CF84046B@ix.netcom.com> Date: Wed, 29 Apr 2009 17:24:47 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ted Lemon CC: Mark Andrews , Namedroppers WG , DHS info , Alan Paller , Stephen Northcutt , FTC IP marketplace comments , FTC OIG's office , HHS OIG Lewis Morris Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904290143.n3T1hmUG097300@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606888f85f52258b34b351025b84758031f71350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.55 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ted and all, What do you recommend as a method of getting Microsoft and Apple to cooperate with implementing DHCPv6? What do you also recommend that can be done if Microsoft and Apple are not willing to cooperate on implementing DHCPv6, be done by providers and/or Domain Name holders? BTW, we have a solution that works to prevent intercepting DNS, but I was interested in what you might suggest as a solution.... We view the intercepting DNS as a security breach and treat it accordingly. Ted Lemon wrote: > [ 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. ] > > On Apr 28, 2009, at 8:43 PM, Mark Andrews wrote: > > We should just stop trying to intercept things in hot spots > > and define a DHCP element that says where to go to register > > or did AAA do something like that. I never followed AAA > > in enough detail to know. > > "We" aren't intercepting DNS in hot spots. I agree that it's the > wrong thing to do, but the problem is that it's working, and when > things work, it's hard to get the people benefiting from them to do > something different, particularly when it requires coordinated > deployment. I think probably the guys at FON would be the ones to > talk to if we want to do something through DHCP, but the problem is > that we have very little to offer them unless Microsoft and Apple are > willing to implement the other side of it. Apple doesn't do DHCPv6, > so it's going to be kind of hard to make progress there with a DHCPv6 > option. > > So I agree in principle that what you are saying makes sense, but I > don't see quite as clear a path forward as the one you suggest. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From serbera@kwaiyanwatch.com Wed Apr 29 18:34:42 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6763A6E42; Wed, 29 Apr 2009 18:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.861 X-Spam-Level: X-Spam-Status: No, score=-6.861 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 F48NdsOLPfn5; Wed, 29 Apr 2009 18:34:41 -0700 (PDT) Received: from cpe-24-94-7-57.san.res.rr.com (cpe-24-94-7-57.san.res.rr.com [24.94.7.57]) by core3.amsl.com (Postfix) with SMTP id 5268928C0EA; Wed, 29 Apr 2009 18:34:37 -0700 (PDT) From: "Prince Chavez" TO: <"disman-bounces@ietf.org, disman-owner@ietf.org, disman-request@ietf.org, dix@ietf.org, dix-request@ietf.org, dnsext-archive@ietf.org, dnsind-archive@ietf.org, dnsop"@ietf.org> Subject: Omega watch models from 2009! Date: Wed, 29 Apr 2009 21:36:02 -0500 Message-ID: <65220ykpb090BWIJLdisman-bounces@ietf.org> Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It's the perfect time to get that dream watch you've fantasized about. But there's no need to empty your bank account while doing it! http://bopikaquj.cn Visit Diam0nd Reps today and get a terrific designer watch imitation for a uniquely low price. Our watches are the most sought-after in the market, offering you the best performance and unsurpassed quality while allowing you to choose from hundreds of models within dozens of brands! http://bopikaquj.cn Check out our extensive inventory and enjoy the fastest shipping available online! See you at Diam0nd Reps! From owner-namedroppers@ops.ietf.org Wed Apr 29 21:16:38 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231B53A6B3C; Wed, 29 Apr 2009 21:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.143 X-Spam-Level: X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=-0.648, 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 kKqa-MTMdBeO; Wed, 29 Apr 2009 21:16:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 899FA3A6A29; Wed, 29 Apr 2009 21:16:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzNbS-0001l7-Ps for namedroppers-data0@psg.com; Thu, 30 Apr 2009 04:10:30 +0000 Received: from [64.18.14.205] (helo=chip3mo2-old.postini.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzNbG-0001kN-M3 for namedroppers@ops.ietf.org; Thu, 30 Apr 2009 04:10:24 +0000 Received: from source ([64.89.228.229]) (using TLSv1) by chip3ob64.postini.com ([64.18.6.12]) with SMTP ID DSNKSfkkqLRh5WC9BaKtc+rwUuqQyndCrOM8@postini.com; Wed, 29 Apr 2009 21:10:18 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E5DD61B831E; Wed, 29 Apr 2009 21:10:29 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 29 Apr 2009 21:10:15 -0700 CC: Mark Andrews , Namedroppers WG Message-ID: From: Ted Lemon To: Jeffrey A.Williams In-Reply-To: <49F8EFCF.CF84046B@ix.netcom.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? Date: Wed, 29 Apr 2009 23:10:12 -0500 References: <200904290143.n3T1hmUG097300@drugs.dv.isc.org> <49F8EFCF.CF84046B@ix.netcom.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Apr 29, 2009, at 7:24 PM, Jeffrey A. Williams wrote: > What do you recommend as a method of getting Microsoft and > Apple to cooperate with implementing DHCPv6? Er, to be clear, Microsoft has an excellent DHCPv6 client implementation (possibly an excellent server as well, but I haven't tried it). Apple's stated preference thus far, as I understand it (obviously I don't speak for them!), has been to use stateless autoconf and to extract other configuration information from RA packets. Being a non-Apple employee, I have no information about Apple's plans with respect to DNSSEC validating resolvers in their end- user operating system offerings, although I will say that they are well-positioned to do so given their current name resolution implementation on Mac OS X. In general, solutions to problems like this need to be driven by customer demand. The U.S. government certainly did a very good thing when they drew a line in the sand and insisted that their vendors implement IPv6; I don't know how much influence that had on Microsoft and Apple implementing IPv6, but I'm sure it was a consideration. It's likely that the government could exert some influence here simply by being a customer that wants DNSSEC validating resolvers, and putting it into their procurement requirements. > What do you also recommend that can be done if Microsoft and Apple > are not > willing to cooperate on implementing DHCPv6, be done by providers > and/or Domain Name holders? Boingo wireless and some of the other paid wifi hotspot vendors have clients they ask you to install on your computer, and they fall back to DNS capture if you don't use the client. I don't know how these clients work, but perhaps a standards-based approach based on the same sort of technology would do the job. If you were to use DHCP here, the DHCP authentication protocol already provides a viable solution in this case, since this is the one situation where you probably already have a shared secret that could be used. In this case, the fact that Apple doesn't support DHCPv6 natively might actually be an advantage, since you could install your own client without fear of interfering with the vendor's client. -- to unsubscribe send a message to namedroppers-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 Apr 29 22:18:52 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067D93A684B; Wed, 29 Apr 2009 22:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[AWL=0.812, 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 Y6QNvy-sA0lO; Wed, 29 Apr 2009 22:18:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B17783A6405; Wed, 29 Apr 2009 22:18:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzObf-0006cC-0z for namedroppers-data0@psg.com; Thu, 30 Apr 2009 05:14:47 +0000 Received: from [209.86.89.66] (helo=elasmtp-spurfowl.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzObN-0006a1-Jg for namedroppers@ops.ietf.org; Thu, 30 Apr 2009 05:14:40 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=VDyMGa9tm+px6EdB2juElkp5mmigm6CJ7O9ZxH69ARb2SulMbf2CT3zPRUH/2ZIf; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.227.98.73] (helo=ix.netcom.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LzObJ-0006mK-K9; Thu, 30 Apr 2009 01:14:26 -0400 Message-ID: <49F933A2.1A37FEE1@ix.netcom.com> Date: Wed, 29 Apr 2009 22:14:10 -0700 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ted Lemon CC: Mark Andrews , Namedroppers WG , FTC IP marketplace comments , FTC OIG's office , Alan Paller , HHS OIG Lewis Morris , DHS info Subject: Re: [dnsext] Adopt EDNS0 Ping, benefits vs disadvantages ? References: <200904290143.n3T1hmUG097300@drugs.dv.isc.org> <49F8EFCF.CF84046B@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606887172409c8946c36865de26aeb49a2305350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.98.73 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ted and all, Well Autoconfig has known security problems and should be avoided. So given your response, you don't have a recommendation. Thank you for clarifying that. BTW, in accordance with your response below, "Well positioned" is a far cry from anything resembling implementation or something that "Could" be implemented. Microsoft does not support RFC 3118. Microsofts DHCPv6 is quite error prone and as such demonstrates pretty clearly it's not yet ready for prime time use... As such MS platforms or client services are an obvious security problem that begs a immediate and private industry solution if critical and sensitive data is to be transported or transmitted over an IPv6 network safely. Non-critical or non-sensitive data would be ok for either Apple or MS platforms, but one would need to recognize that at end points such data would be of questionable accuracy and may contain various other harmful records that would cause other data integraty and platform security problems of perhaps unknown types and as such would be difficult to safely, if at all, erradicate fully. Ted Lemon wrote: > On Apr 29, 2009, at 7:24 PM, Jeffrey A. Williams wrote: > > What do you recommend as a method of getting Microsoft and > > Apple to cooperate with implementing DHCPv6? > > Er, to be clear, Microsoft has an excellent DHCPv6 client > implementation (possibly an excellent server as well, but I haven't > tried it). Apple's stated preference thus far, as I understand it > (obviously I don't speak for them!), has been to use stateless > autoconf and to extract other configuration information from RA > packets. Being a non-Apple employee, I have no information about > Apple's plans with respect to DNSSEC validating resolvers in their end- > user operating system offerings, although I will say that they are > well-positioned to do so given their current name resolution > implementation on Mac OS X. > > In general, solutions to problems like this need to be driven by > customer demand. The U.S. government certainly did a very good thing > when they drew a line in the sand and insisted that their vendors > implement IPv6; I don't know how much influence that had on Microsoft > and Apple implementing IPv6, but I'm sure it was a consideration. > It's likely that the government could exert some influence here simply > by being a customer that wants DNSSEC validating resolvers, and > putting it into their procurement requirements. > > > What do you also recommend that can be done if Microsoft and Apple > > are not > > willing to cooperate on implementing DHCPv6, be done by providers > > and/or Domain Name holders? > > Boingo wireless and some of the other paid wifi hotspot vendors have > clients they ask you to install on your computer, and they fall back > to DNS capture if you don't use the client. I don't know how these > clients work, but perhaps a standards-based approach based on the same > sort of technology would do the job. > > If you were to use DHCP here, the DHCP authentication protocol already > provides a viable solution in this case, since this is the one > situation where you probably already have a shared secret that could > be used. In this case, the fact that Apple doesn't support DHCPv6 > natively might actually be an advantage, since you could install your > own client without fear of interfering with the vendor's client. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 -- to unsubscribe send a message to namedroppers-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 Apr 30 06:33:39 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11E228C34F; Thu, 30 Apr 2009 06:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.100, 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 nxaPmpzFFAxe; Thu, 30 Apr 2009 06:33:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6821628C337; Thu, 30 Apr 2009 06:33:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzWIi-000I5F-Ie for namedroppers-data0@psg.com; Thu, 30 Apr 2009 13:27:44 +0000 Received: from [209.85.219.159] (helo=mail-ew0-f159.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LzWIP-000I2e-0S for namedroppers@ops.ietf.org; Thu, 30 Apr 2009 13:27:38 +0000 Received: by ewy3 with SMTP id 3so77479ewy.41 for ; Thu, 30 Apr 2009 06:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=XsKABp15czRRHXOKCtiXWVleDABmf88dkkCaz0nlQgA=; b=wqXwyozmEE1eAPQc7Z4u2eQfPF3IZMSohQr+DiNQW0nsWPF3uzZKJQmz8KmdmoV0Yf yV3vXOFUJf3yKi19fdTbTt2RnT5cM08YVJVjPFfi+9ESn450s5l79muKZ6OsUrgGDEUK IrGWJHt087rl8tPL0yPbmHdCYX/8oZmY3443Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=kwlvs7Q6Ie6+xrTSwg2Ewyzx4D6VMk1qOpQKwivgRaZHx/TqSHCHo1gBcIiOTN50sO PFtzvcDFOKfQ29iNmzmY457ZiIq26gK84vKkBPyATw3wuXYpxJUaT3mfNHDJawh0Enec wxBCUbfJh2kUNsxSUQNfl92NVK8l6OVnV58bQ= Received: by 10.210.19.7 with SMTP id 7mr1706342ebs.5.1241098043005; Thu, 30 Apr 2009 06:27:23 -0700 (PDT) Received: from ?192.168.1.204? ([193.82.161.205]) by mx.google.com with ESMTPS id 2sm141556ewy.14.2009.04.30.06.27.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 06:27:22 -0700 (PDT) Cc: IETF DNSEXT WG Message-Id: <7D1242CF-1F0C-405D-934B-427ADA79F11B@jadickinson.co.uk> From: John Dickinson To: Michael StJohns In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [dnsext] SEP bit Date: Thu, 30 Apr 2009 14:27:21 +0100 References: X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On 29 Apr 2009, at 21:04, Michael StJohns wrote: > Except see RFC5011. Keys with the SEP bit set are the only ones > tracked by the key rollover mechanism described there. Sorry for my almost unreadably formatted message (it looked OK until I pressed send) and for bringing 4641 into the wrong list. Perhaps it would be useful if draft-ietf-dnsext-dnssec-bis-updates clarified this and section 5.2 included something to the effect that: RFC3757 is not obsolete, that it is updated by RFC5011 and that although the SEP bit plays no part in the validation process it may be used in the automated key rollover process as described in RFC5011. Reading 5011 and dnssec-bis-updates again also made me wonder how the operator of a validator is supposed to know that the zone owner is doing RFC5011 and using the SEP bit in a meaningful way? Should dnssec- bis-updates make some comment on that? John > > > At 12:06 PM 4/29/2009, John Dickinson wrote: >> Whilst trying to explain the meaning of the SEP bit in a document I >> am >> writing I found that >> >> RFC4033 says "This document and its two companions obsolete >> [RFC3757]" >> >> However, I can not see where this is done in any of 4033-35. >> >> In fact 4033 goes on to say: >> >> "Key signing keys are discussed in more detail in [RFC3757]." >> >> 4034 says: >> "Bit 15 of the Flags field is the Secure Entry Point flag, described >> in [RFC3757]" >> "and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757])" >> "This flag is only intended to be a hint to zone signing or debugging >> software as to the intended use of this DNSKEY record; validators >> MUST >> NOT alter their behavior during the signature validation process in >> any way based on the setting of this bit." which by my reading >> doesn't >> seem to contradict 3757. >> Is RFC3757 really obsolete? >> RFC 4641(bis) goes on to recommend "In this document, we assume a >> one- to-one mapping between KSK and SEP keys and we assume the SEP >> flag to >> be set on all KSKs." This seems reasonable unless you don't want to >> use a KSK. >> Are there scenarios where 4641 is not true? It seems that the SEP bit >> is in danger of taking on meaning that it does not have. Most signers >> already call it the KSK flag. >> I am thinking that 4641bis might want to say something like - The SEP >> bit may be used locally only to aid signers in deciding what RRSets >> to >> sign with a given key. However, when signing it would be better to be >> explicit about which keys sign which RRSets. It should not be used >> even between cooperating parties such as a parent and child for >> indicating which key to use for a DS or as a TA. It should be ignored >> by all other systems especially validators. --- John Dickinson http://www.jadickinson.co.uk I am riding from Lands end to John O'Groats to raise money for Parkinson's Disease Research. Please sponsor me here http://justgiving.com/pedalforparkinsons2009 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From majordomo@ambiancearchitect.com Thu Apr 30 20:29:56 2009 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F70A3A69A4 for ; Thu, 30 Apr 2009 20:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.254 X-Spam-Level: **** X-Spam-Status: No, score=4.254 tagged_above=-999 required=5 tests=[APOSTROPHE_FROM=0.001, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_16=1.526, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 smzmyTFSC2gv for ; Thu, 30 Apr 2009 20:29:49 -0700 (PDT) Received: from 85.155.247.182.dyn.user.ono.com (85.155.247.182.dyn.user.ono.com [85.155.247.182]) by core3.amsl.com (Postfix) with SMTP id 6A6C63A67E6 for ; Thu, 30 Apr 2009 20:28:42 -0700 (PDT) To: " Date: Thu, 30 Apr 2009 20:28:42 -0700 (PDT)

Read more
Copyright
Unsubscribe | Your Privacy Rights

2008 Rodale Inc., all rights reserved.
Customer Service Department, 33 East Minor Street, Emmaus, PA 18098