Re: [dnsext] AXFR Clarify -- open issue w/ 'zone loading'

Please do not reply to this email. To contact Darkhorse Creative, please visit us

If you do not wish to receive further communications from Darkhorse Creative, click here to unsubscribe.
If you've experience any difficulty in being removed from a Darkhorse Creative email list, click here for personalized help.

Copyright Â© 2008 Darkhorse Creative, Inc. All rights reserved.
217- La Grange Rd, PEWEE VALLEY, KY 40056

Health Monthly

Drug Factsheets

Condition Factsheets

Ask an Expert

Community Support

X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E590628C120 for ; Mon, 12 Jan 2009 04:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.422 X-Spam-Level: X-Spam-Status: No, score=-47.422 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, 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 c8HcdIPms7I7 for ; Mon, 12 Jan 2009 04:20:58 -0800 (PST) Received: from 1up.com (unknown [87.18.198.186]) by core3.amsl.com (Postfix) with SMTP id 0E7D03A6A17 for ; Mon, 12 Jan 2009 04:20:55 -0800 (PST) To: Subject: Gives you more than just e-mail in October? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112122057.0E7D03A6A17@core3.amsl.com> Date: Mon, 12 Jan 2009 04:20:55 -0800 (PST)

Microsoft respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive promotional offers or research emails from MSN or Windows Live, please click to "unsubscribe" or reply to this message with "UNSUBSCRIBE" in the subject line. To set your contact preferences for other Microsoft communications, see the communications preferences section of the Privacy Statement.

Â©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation One Microsoft Way Redmond, WA 67729

From owner-namedroppers@ops.ietf.org Mon Jan 12 06:33: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 75BF73A6955; Mon, 12 Jan 2009 06:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 vB76Vp7qn+Hc; Mon, 12 Jan 2009 06:33:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7CBA73A67AF; Mon, 12 Jan 2009 06:33:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMNga-0001US-Jj for namedroppers-data0@psg.com; Mon, 12 Jan 2009 14:22: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 1LMNgV-0001Tx-Nd for namedroppers@ops.ietf.org; Mon, 12 Jan 2009 14:22:33 +0000 Received: from [0.0.0.0] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0CEMKX0013770; Mon, 12 Jan 2009 09:22:26 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <18792.49369.190133.315605@guava.gson.org> References: <18792.49369.190133.315605@guava.gson.org> Date: Mon, 12 Jan 2009 09:13:02 -0500 To: gson@araneus.fi (Andreas Gustafsson) From: Edward Lewis Subject: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies Cc: Edward Lewis , 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: Thanks for pointing that out. At 17:38 +0200 1/10/09, Andreas Gustafsson wrote: >draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6): > > Note that TSIG and SIG(0), if in use, will treat each individual > AXFR response message within a session as a unit of data. That is, > each message will have a TSIG or SIG(0) (if in use) and the > cryptographic check will cover just that message. > >That's not what the TSIG specification says. According to RFC2845 >section 4.4, the TSIG does not have to be present on every message >(only at least every 100th message), and does not cover just that >message but the "Prior Digest", every unsigned message since the last >TSIG, and the "TSIG Timers". > >I suggest removing the paragraph containing the quoted text. >-- >Andreas Gustafsson, gson@araneus.fi -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From jresume@21imagetech.com Mon Jan 12 14:52: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 3D3023A6997 for ; Mon, 12 Jan 2009 14:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.899 X-Spam-Level: X-Spam-Status: No, score=-30.899 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_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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, 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 y23Jto4WZFd5 for ; Mon, 12 Jan 2009 14:52:18 -0800 (PST) Received: from 189-87-70-128.rec.megazon.com.br (189-87-70-128.rec.megazon.com.br [189.87.70.128]) by core3.amsl.com (Postfix) with SMTP id E20C83A6903 for ; Mon, 12 Jan 2009 14:52:13 -0800 (PST) To: Subject: RE: Message 56860 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112225214.E20C83A6903@core3.amsl.com> Date: Mon, 12 Jan 2009 14:52:13 -0800 (PST)

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

Â©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 78654

From jeremyad@afo.net Mon Jan 12 21:03: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 5D7183A63EC for ; Mon, 12 Jan 2009 21:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.66 X-Spam-Level: X-Spam-Status: No, score=0.66 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, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, 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 o0MsjoAV4zfu for ; Mon, 12 Jan 2009 21:03:34 -0800 (PST) Received: from 201.54.9.74.rev.neoviatelecom.com.br (201.54.9.74.rev.neoviatelecom.com.br [201.54.9.74]) by core3.amsl.com (Postfix) with SMTP id 6EE0E3A63EB for ; Mon, 12 Jan 2009 21:03:32 -0800 (PST) To: Subject: RE: Message 98632 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113050333.6EE0E3A63EB@core3.amsl.com> Date: Mon, 12 Jan 2009 21:03:32 -0800 (PST)

From makoto-asahi@agc.co.jp Tue Jan 13 03:41: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 39FEC3A6943 for ; Tue, 13 Jan 2009 03:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.686 X-Spam-Level: X-Spam-Status: No, score=-12.686 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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_XBL=3.033, RDNS_NONE=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 Rc7yqPU5AFHi for ; Tue, 13 Jan 2009 03:41:40 -0800 (PST) Received: from aisd.net (unknown [61.11.74.194]) by core3.amsl.com (Postfix) with SMTP id 68B513A68B0 for ; Tue, 13 Jan 2009 03:41:38 -0800 (PST) To: Subject: Your order 01685 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113114139.68B513A68B0@core3.amsl.com> Date: Tue, 13 Jan 2009 03:41:38 -0800 (PST)

From owner-namedroppers@ops.ietf.org Tue Jan 13 10:04: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 1184828C11C; Tue, 13 Jan 2009 10:04:29 -0800 (PST) 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 1-73TplXJ5x1; Tue, 13 Jan 2009 10:04:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCA353A67E9; Tue, 13 Jan 2009 10:04:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMnT3-000PA1-PC for namedroppers-data0@psg.com; Tue, 13 Jan 2009 17:54:21 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMnSy-000P9W-KC for namedroppers@ops.ietf.org; Tue, 13 Jan 2009 17:54:18 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n0DHsIDp019544 for ; Tue, 13 Jan 2009 12:54:19 -0500 Message-ID: <496CD541.7040301@nist.gov> Date: Tue, 13 Jan 2009 12:54:09 -0500 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt References: <20090109084501.BA9953A692D@core3.amsl.com> <49671317.3050705@NLnetLabs.nl> In-Reply-To: <49671317.3050705@NLnetLabs.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Is this (hopefully) the final working version? I have read it and support this draft moving forward. Scott Jelte Jansen wrote: > 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 >> Author(s) : J. Jansen >> Filename : draft-ietf-dnsext-dnssec-rsasha256-10.txt >> Pages : 8 >> Date : 2009-01-08 > > > I've opted for the second option from my previous suggestion, and worked in the > comments from the list (thanks!) > > wdiff at: > > http://nlnetlabs.nl/downloads/publications/draft-ietf-dnsext-dnssec-rsasha256-wdiff-09-10.html > > 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 Jan 13 10:45: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 E7C603A6828; Tue, 13 Jan 2009 10:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRuznPrJEVPM; Tue, 13 Jan 2009 10:45:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8CAD3A6802; Tue, 13 Jan 2009 10:45:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMo8M-0002UH-CR for namedroppers-data0@psg.com; Tue, 13 Jan 2009 18:37:02 +0000 Received: from [76.96.30.96] (helo=QMTA09.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMo8E-0002Tp-Va for namedroppers@ops.ietf.org; Tue, 13 Jan 2009 18:36:59 +0000 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 33uo1b00217UAYkA96cuz1; Tue, 13 Jan 2009 18:36:54 +0000 Received: from MIKES-LAPTOM.comcast.net ([12.235.127.2]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id 36cc1b00S03E9MG8Z6cf9R; Tue, 13 Jan 2009 18:36:51 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Jan 2009 13:36:35 -0500 To: Edward Lewis ,gson@araneus.fi (Andreas Gustafsson) From: Michael StJohns Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies Cc: Edward Lewis ,namedroppers@ops.ietf.org In-Reply-To: References: <18792.49369.190133.315605@guava.gson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: Isn't it a true statement that TSIG (2845) sets minimum requirements (e.g. at least one TSIG per 100), but that AXFR clarify can specify more stringent requirements - (e.g. a TSIG per message)? One of the processing issues here is that you must wait until you see a TSIG before committing AXFR changes. From a simplicity POV placing a TSIG in each message may be the right approach. On the other hand, it may make sense to weaken 2845 and only provide a TSIG in the last message before closing an AXFR session within a TCP session. And can you mix and match TSIG signers (e.g. different key ids in the TSIG record) during an update session? So I don't think its as simple as removing the quoted text. Mike At 09:13 AM 1/12/2009, Edward Lewis wrote: >Thanks for pointing that out. > >At 17:38 +0200 1/10/09, Andreas Gustafsson wrote: >>draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6): >> >> Note that TSIG and SIG(0), if in use, will treat each individual >> AXFR response message within a session as a unit of data. That is, >> each message will have a TSIG or SIG(0) (if in use) and the >> cryptographic check will cover just that message. >> >>That's not what the TSIG specification says. According to RFC2845 >>section 4.4, the TSIG does not have to be present on every message >>(only at least every 100th message), and does not cover just that >>message but the "Prior Digest", every unsigned message since the last >>TSIG, and the "TSIG Timers". >> >>I suggest removing the paragraph containing the quoted text. >>-- >>Andreas Gustafsson, gson@araneus.fi > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis >NeuStar You can leave a voice message at +1-571-434-5468 > >Never confuse activity with progress. Activity pays more. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 13 10:56: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 B6BC63A6A3C; Tue, 13 Jan 2009 10:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 HaZlJ186hQn3; Tue, 13 Jan 2009 10:56:35 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA55F3A6874; Tue, 13 Jan 2009 10:56:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMoIE-00039E-TP for namedroppers-data0@psg.com; Tue, 13 Jan 2009 18:47:14 +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 1LMoI5-00038L-1w for namedroppers@ops.ietf.org; Tue, 13 Jan 2009 18:47:09 +0000 Received: from [10.31.201.29] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0DIkxkf027531; Tue, 13 Jan 2009 13:46:59 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18792.49369.190133.315605@guava.gson.org> Date: Tue, 13 Jan 2009 13:46:56 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies 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: I don't think mixing and matching would work - the TSIG respondent uses the key named by the TSIG requestor. The respondent does not know what key the requestor has (or still has). I'm neutral on the other issue - AXFR could say one each per message or stay as "lax" as the TSIG spec. What do others say? At 13:36 -0500 1/13/09, Michael StJohns wrote: >Isn't it a true statement that TSIG (2845) sets minimum requirements >(e.g. at least one TSIG per 100), but that AXFR clarify can specify >more stringent requirements - (e.g. a TSIG per message)? > >One of the processing issues here is that you must wait until you >see a TSIG before committing AXFR changes. From a simplicity POV >placing a TSIG in each message may be the right approach. > >On the other hand, it may make sense to weaken 2845 and only provide >a TSIG in the last message before closing an AXFR session within a >TCP session. > >And can you mix and match TSIG signers (e.g. different key ids in >the TSIG record) during an update session? > >So I don't think its as simple as removing the quoted text. > >Mike > > >At 09:13 AM 1/12/2009, Edward Lewis wrote: >>Thanks for pointing that out. >> >>At 17:38 +0200 1/10/09, Andreas Gustafsson wrote: >>>draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6): >>> >>> Note that TSIG and SIG(0), if in use, will treat each individual >>> AXFR response message within a session as a unit of data. That is, >>> each message will have a TSIG or SIG(0) (if in use) and the >>> cryptographic check will cover just that message. >>> >>>That's not what the TSIG specification says. According to RFC2845 >>>section 4.4, the TSIG does not have to be present on every message >>>(only at least every 100th message), and does not cover just that >>>message but the "Prior Digest", every unsigned message since the last >>>TSIG, and the "TSIG Timers". >>> >>>I suggest removing the paragraph containing the quoted text. >>>-- >>>Andreas Gustafsson, gson@araneus.fi >> >>-- >>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>Edward Lewis >>NeuStar You can leave a voice message at +1-571-434-5468 >> >>Never confuse activity with progress. Activity pays more. >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 13 11:17: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 651D43A6869; Tue, 13 Jan 2009 11:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[AWL=-0.480, 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 41srKxspuhBg; Tue, 13 Jan 2009 11:17:25 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 907F33A6802; Tue, 13 Jan 2009 11:17:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMoax-0004Vi-C6 for namedroppers-data0@psg.com; Tue, 13 Jan 2009 19:06:35 +0000 Received: from [168.150.236.43] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMoae-0004TN-VB for namedroppers@ops.ietf.org; Tue, 13 Jan 2009 19:06:27 +0000 Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 696BE39A0FC for ; Tue, 13 Jan 2009 11:06:14 -0800 (PST) From: Wes Hardaker To: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt Organization: Sparta References: <20090109084501.BA9953A692D@core3.amsl.com> <49671317.3050705@NLnetLabs.nl> <496CD541.7040301@nist.gov> Date: Tue, 13 Jan 2009 11:06:14 -0800 In-Reply-To: <496CD541.7040301@nist.gov> (Scott Rose's message of "Tue, 13 Jan 2009 12:54:09 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: I have also read the diff and like the new version but with one question: 5.2.2. NSEC3 in Validators A DNSSEC validator that implements RSA/SHA2 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/SHA256 or RSA/ SHA512 as signed with an unknown algorithm, and thus as insecure. Shouldn't that be phrased in a way that allows understanding one or the other of NSEC vs NSEC3? Right now it states that if you don't understand either you can't validate a zone that you do understand the contents of. IE, if you don't handle NSEC3 you must treat NSEC3 zones as insecure but can still treat NSEC zones as secure. That's what I thought the consensus led to. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 13 12:47: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 168BA28C0E2; Tue, 13 Jan 2009 12:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 iwpJC6DDa9S8; Tue, 13 Jan 2009 12:46:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 001F228C0DC; Tue, 13 Jan 2009 12:46:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMq1y-000ALs-1T for namedroppers-data0@psg.com; Tue, 13 Jan 2009 20:38: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 1LMq1o-000ALC-CQ for namedroppers@ops.ietf.org; Tue, 13 Jan 2009 20:38:30 +0000 Received: from [10.31.201.29] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0DKcIMv028577; Tue, 13 Jan 2009 15:38:18 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18792.49369.190133.315605@guava.gson.org> Date: Tue, 13 Jan 2009 15:38:13 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies 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: Expanding more on the suggestion to restrict TSIG for AXFR to each message (as opposed to not): - During the development of DNSSEC, there was once an AXFR signature. It came at the conclusion of the transfer and was cognizant of the order of the records. During early prototyping, it proved to be too much of a pain, further, it was redundant to the information in the NXT and NXT signatures. The TSIG spec is not exactly the same. My first concern about using one TSIG for multiple (or all) the messages in an AXFR response is reordering - but AXFR has to be in (MUST) TCP or (theoretically) any stream-oriented protocol. TSIG only looks at messages, not the data inside, as did the AXFR signatures. Don't know what that means significance-wise. - To me the issue is whether we want AXFR to odd-ball the TSIG spec by doing one message per TSIG or have to put up with the overhead of having to hold back a pool (FIFO buffer) of messages until the TSIG appears for the check. At 13:46 -0500 1/13/09, Edward Lewis wrote: >I don't think mixing and matching would work - the TSIG respondent >uses the key named by the TSIG requestor. The respondent does not >know what key the requestor has (or still has). > >I'm neutral on the other issue - AXFR could say one each per message >or stay as "lax" as the TSIG spec. What do others say? > >At 13:36 -0500 1/13/09, Michael StJohns wrote: >>Isn't it a true statement that TSIG (2845) sets minimum >>requirements (e.g. at least one TSIG per 100), but that AXFR >>clarify can specify more stringent requirements - (e.g. a TSIG per >>message)? >> >>One of the processing issues here is that you must wait until you >>see a TSIG before committing AXFR changes. From a simplicity POV >>placing a TSIG in each message may be the right approach. >> >>On the other hand, it may make sense to weaken 2845 and only >>provide a TSIG in the last message before closing an AXFR session >>within a TCP session. >> >>And can you mix and match TSIG signers (e.g. different key ids in >>the TSIG record) during an update session? >> >>So I don't think its as simple as removing the quoted text. >> >>Mike >> >> >>At 09:13 AM 1/12/2009, Edward Lewis wrote: >>>Thanks for pointing that out. >>> >>>At 17:38 +0200 1/10/09, Andreas Gustafsson wrote: >>>>draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6): >>>> >>>> Note that TSIG and SIG(0), if in use, will treat each individual >>>> AXFR response message within a session as a unit of data. That is, >>>> each message will have a TSIG or SIG(0) (if in use) and the >>>> cryptographic check will cover just that message. >>>> >>>>That's not what the TSIG specification says. According to RFC2845 >>>>section 4.4, the TSIG does not have to be present on every message >>>>(only at least every 100th message), and does not cover just that >>>>message but the "Prior Digest", every unsigned message since the last >>>>TSIG, and the "TSIG Timers". >>>> >>>>I suggest removing the paragraph containing the quoted text. >>>>-- >>>>Andreas Gustafsson, gson@araneus.fi >>> >>>-- >>>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>Edward Lewis >>>NeuStar You can leave a voice message at +1-571-434-5468 >>> >>>Never confuse activity with progress. Activity pays more. >>> >>>-- >>>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>>the word 'unsubscribe' in a single line as the message text body. >>>archive: > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis >NeuStar You can leave a voice message at +1-571-434-5468 > >Never confuse activity with progress. Activity pays more. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 00:50: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 D4B583A681C; Wed, 14 Jan 2009 00:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, 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 mIE-FesPp3hu; Wed, 14 Jan 2009 00:50:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA41B3A6B2C; Wed, 14 Jan 2009 00:50:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN1ET-00059U-DH for namedroppers-data0@psg.com; Wed, 14 Jan 2009 08:36:13 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN1EB-000589-FT for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 08:36:07 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 2FEB9272CDF; Wed, 14 Jan 2009 09:35:52 +0100 (CET) Received: from [192.168.254.3] (unknown [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTP id EE018272C88; Wed, 14 Jan 2009 09:35:44 +0100 (CET) Message-ID: <496DA3E0.7070308@nlnetlabs.nl> Date: Wed, 14 Jan 2009 09:35:44 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Wes Hardaker CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt References: <20090109084501.BA9953A692D@core3.amsl.com> <49671317.3050705@NLnetLabs.nl> <496CD541.7040301@nist.gov> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/8863/Wed Jan 14 08:08:56 2009 on rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wes Hardaker wrote: > I have also read the diff and like the new version but with one > question: > > 5.2.2. NSEC3 in Validators > > A DNSSEC validator that implements RSA/SHA2 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/SHA256 or RSA/ > SHA512 as signed with an unknown algorithm, and thus as insecure. > > Shouldn't that be phrased in a way that allows understanding one or the > other of NSEC vs NSEC3? Right now it states that if you don't > understand either you can't validate a zone that you do understand the > contents of. IE, if you don't handle NSEC3 you must treat NSEC3 zones > as insecure but can still treat NSEC zones as secure. That's what I > thought the consensus led to. Hi Wes, I also think this is where consensus led. I think the draft describes it. Treating NSEC3 zones as insecure is one way of 'handling' NSEC3. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklto+AACgkQkDLqNwOhpPjuQgCfTprpazc75qf0J4SHbIC71wkv 234AniDr0hG5vrksa4U4hMtkgNJfC1xr =9uZp -----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 Wed Jan 14 00:57: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 5411E3A681C; Wed, 14 Jan 2009 00:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 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, 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 GkBCDVA4DRMG; Wed, 14 Jan 2009 00:57:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C8C13A67F2; Wed, 14 Jan 2009 00:57:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN1S4-00069g-TS for namedroppers-data0@psg.com; Wed, 14 Jan 2009 08:50:16 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN1Rz-00069C-52 for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 08:50:14 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 70ECD272CE4; Wed, 14 Jan 2009 09:50:10 +0100 (CET) Received: from [192.168.254.3] (unknown [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTP id 0BC16272C88; Wed, 14 Jan 2009 09:50:05 +0100 (CET) Message-ID: <496DA73D.8090804@nlnetlabs.nl> Date: Wed, 14 Jan 2009 09:50:05 +0100 From: "W.C.A. Wijngaards" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies References: <18792.49369.190133.315605@guava.gson.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/8863/Wed Jan 14 08:08:56 2009 on rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ed, You cannot commit AXFR changes until you have obtained all of the AXFR data. Since this would also end your TCP stream, I would expect a TSIG over the unauthenticated remainder of the AXFR data. Then you have both the data and TSIG on it. You have to wait anyway, because you have to publish the new serial number in one atomic publication. So, the AXFR is going to sit somewhere in any case until it is complete. That place it can also wait until it is properly authenticated. What I mean to say is, this TSIG problem is not there. Best regards, Wouter Edward Lewis wrote: > Expanding more on the suggestion to restrict TSIG for AXFR to each > message (as opposed to not): > > - During the development of DNSSEC, there was once an AXFR signature. It > came at the conclusion of the transfer and was cognizant of the order of > the records. During early prototyping, it proved to be too much of a > pain, further, it was redundant to the information in the NXT and NXT > signatures. > > The TSIG spec is not exactly the same. My first concern about using one > TSIG for multiple (or all) the messages in an AXFR response is > reordering - but AXFR has to be in (MUST) TCP or (theoretically) any > stream-oriented protocol. > > TSIG only looks at messages, not the data inside, as did the AXFR > signatures. Don't know what that means significance-wise. > > - To me the issue is whether we want AXFR to odd-ball the TSIG spec by > doing one message per TSIG or have to put up with the overhead of having > to hold back a pool (FIFO buffer) of messages until the TSIG appears for > the check. > > At 13:46 -0500 1/13/09, Edward Lewis wrote: >> I don't think mixing and matching would work - the TSIG respondent >> uses the key named by the TSIG requestor. The respondent does not >> know what key the requestor has (or still has). >> >> I'm neutral on the other issue - AXFR could say one each per message >> or stay as "lax" as the TSIG spec. What do others say? >> >> At 13:36 -0500 1/13/09, Michael StJohns wrote: >>> Isn't it a true statement that TSIG (2845) sets minimum requirements >>> (e.g. at least one TSIG per 100), but that AXFR clarify can specify >>> more stringent requirements - (e.g. a TSIG per message)? >>> >>> One of the processing issues here is that you must wait until you see >>> a TSIG before committing AXFR changes. From a simplicity POV placing >>> a TSIG in each message may be the right approach. >>> >>> On the other hand, it may make sense to weaken 2845 and only provide >>> a TSIG in the last message before closing an AXFR session within a >>> TCP session. >>> >>> And can you mix and match TSIG signers (e.g. different key ids in the >>> TSIG record) during an update session? >>> >>> So I don't think its as simple as removing the quoted text. >>> >>> Mike >>> >>> >>> At 09:13 AM 1/12/2009, Edward Lewis wrote: >>>> Thanks for pointing that out. >>>> >>>> At 17:38 +0200 1/10/09, Andreas Gustafsson wrote: >>>>> draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6): >>>>> >>>>> Note that TSIG and SIG(0), if in use, will treat each individual >>>>> AXFR response message within a session as a unit of data. >>>>> That is, >>>>> each message will have a TSIG or SIG(0) (if in use) and the >>>>> cryptographic check will cover just that message. >>>>> >>>>> That's not what the TSIG specification says. According to RFC2845 >>>>> section 4.4, the TSIG does not have to be present on every message >>>>> (only at least every 100th message), and does not cover just that >>>>> message but the "Prior Digest", every unsigned message since the last >>>>> TSIG, and the "TSIG Timers". >>>>> >>>>> I suggest removing the paragraph containing the quoted text. >>>>> -- >>>>> Andreas Gustafsson, gson@araneus.fi >>>> >>>> -- >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>> >>>> Edward Lewis >>>> NeuStar You can leave a voice message at >>>> +1-571-434-5468 >>>> >>>> Never confuse activity with progress. Activity pays more. >>>> >>>> -- >>>> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>>> the word 'unsubscribe' in a single line as the message text body. >>>> archive: >> >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> >> Edward Lewis >> NeuStar You can leave a voice message at >> +1-571-434-5468 >> >> Never confuse activity with progress. Activity pays more. >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkltpz0ACgkQkDLqNwOhpPiTzgCeKiy9qeK/HyQIO99D6r0yNIaF Z0kAoJakeRF7Xuc9EzQJ9u1L3UHsPzRj =3NcF -----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 Wed Jan 14 01:14: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 05B8128C1C5; Wed, 14 Jan 2009 01:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[AWL=-0.484, 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 1KgZIbUvEY4F; Wed, 14 Jan 2009 01:14:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC7043A6B43; Wed, 14 Jan 2009 01:14:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN1j1-0007PN-Fg for namedroppers-data0@psg.com; Wed, 14 Jan 2009 09:07:47 +0000 Received: from [213.154.224.43] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN1in-0007Ns-Nn for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 09:07:41 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 6E79013145A; Wed, 14 Jan 2009 10:07:32 +0100 (CET) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 4E306CFA0D; Wed, 14 Jan 2009 10:09:45 +0100 (CET) Message-ID: <496DAB53.1020408@NLnetLabs.nl> Date: Wed, 14 Jan 2009 10:07:31 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "W.C.A. Wijngaards" CC: Wes Hardaker , namedroppers@ops.ietf.org Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt References: <20090109084501.BA9953A692D@core3.amsl.com> <49671317.3050705@NLnetLabs.nl> <496CD541.7040301@nist.gov> <496DA3E0.7070308@nlnetlabs.nl> In-Reply-To: <496DA3E0.7070308@nlnetlabs.nl> X-Enigmail-Version: 0.95.0 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 W.C.A. Wijngaards wrote: > Wes Hardaker wrote: >> I have also read the diff and like the new version but with one >> question: > >> 5.2.2. NSEC3 in Validators > >> A DNSSEC validator that implements RSA/SHA2 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/SHA256 or RSA/ >> SHA512 as signed with an unknown algorithm, and thus as insecure. > >> Shouldn't that be phrased in a way that allows understanding one or the >> other of NSEC vs NSEC3? Right now it states that if you don't >> understand either you can't validate a zone that you do understand the >> contents of. IE, if you don't handle NSEC3 you must treat NSEC3 zones >> as insecure but can still treat NSEC zones as secure. That's what I >> thought the consensus led to. > > Hi Wes, > > I also think this is where consensus led. I think the draft describes > it. Treating NSEC3 zones as insecure is one way of 'handling' NSEC3. > I think using 'either' in conjunction with 'not' is a recipe for confusion. That is why i've removed at least that sentence from the draft text. And I think that's what's happening here again; Wes thinks consensus leads to the scenario where the validator will verify the zone if it contains the NSEC type you understand. Please correct me if i'm wrong. Wouter (and me as well, for that matter) thinks consensus leads to 'don't verify the zone if you don't know NSEC3, because you cannot know beforehand whether it will be used'). So maybe we should have an old school consensus call. I think the current text describes the latter clearly. If not, please suggest text. Without the word 'either' ;) and just to recap the argument that made me favour the don't-do-it scenario; in that case you would get a positive-only scenario if you don't understand NSEC3. For the 'current' zone and all those beneath it... Which for me would probably be a reason not to deploy sha2 at all in my zones. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkltq1EACgkQ4nZCKsdOncX8VwCfVJJdIIOOaIKsePJDKNggMmIL J44An0IpXUwJdfDjhjMWDisYO19iUl6+ =eq1X -----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 mbraithwaite@adsmundo.cl Wed Jan 14 05:14: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 BEB053A6B47 for ; Wed, 14 Jan 2009 05:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.858 X-Spam-Level: X-Spam-Status: No, score=-40.858 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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, 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 RtAM3dYmvufY for ; Wed, 14 Jan 2009 05:14:30 -0800 (PST) Received: from 73-239.ilabs.pl (73-239.ilabs.pl [80.54.73.239]) by core3.amsl.com (Postfix) with SMTP id 97FFD28C10F for ; Wed, 14 Jan 2009 05:14:28 -0800 (PST) To: Subject: RE: Message 21407 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114131429.97FFD28C10F@core3.amsl.com> Date: Wed, 14 Jan 2009 05:14:28 -0800 (PST)

From miguelangel.quintero@alu.uhu.es Wed Jan 14 06:43: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 A23A43A69D3 for ; Wed, 14 Jan 2009 06:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.839 X-Spam-Level: X-Spam-Status: No, score=-33.839 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, GB_I_LETTER=-2, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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_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 SyBGmTxLh9dV for ; Wed, 14 Jan 2009 06:42:55 -0800 (PST) Received: from 216.Red-83-36-42.dynamicIP.rima-tde.net (216.Red-83-36-42.dynamicIP.rima-tde.net [83.36.42.216]) by core3.amsl.com (Postfix) with SMTP id 4D2B53A6880 for ; Wed, 14 Jan 2009 06:42:53 -0800 (PST) To: Subject: Your order 88709 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114144254.4D2B53A6880@core3.amsl.com> Date: Wed, 14 Jan 2009 06:42:53 -0800 (PST)

From owner-namedroppers@ops.ietf.org Wed Jan 14 07:04: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 DF2683A69D6; Wed, 14 Jan 2009 07:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 Gk0pEbhOSynt; Wed, 14 Jan 2009 07:04:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ACE33A69D3; Wed, 14 Jan 2009 07:04:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN794-0005N0-QD for namedroppers-data0@psg.com; Wed, 14 Jan 2009 14:55:02 +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 1LN78y-0005LW-Nu for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 14:54:59 +0000 Received: from [10.31.201.29] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0EEshij037138; Wed, 14 Jan 2009 09:54:43 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <496DA73D.8090804@nlnetlabs.nl> References: <18792.49369.190133.315605@guava.gson.org> <496DA73D.8090804@nlnetlabs.nl> Date: Wed, 14 Jan 2009 09:48:57 -0500 To: "W.C.A. Wijngaards" From: Edward Lewis Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies Cc: Edward Lewis , 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: I think there maybe some confusion over "commit." Yes, only after the "ZIT" completes and is whole is it committed to being the "ZIP." (T/P = Transfer/Published from an earlier email.) But, when AXFR messages are being received, the ZIT is being built up in memory - that is the commit in question, e.g., how many messages do I have to hold before editing the ZIT copy? At 9:50 +0100 1/14/09, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Ed, > >You cannot commit AXFR changes until you have obtained all of the AXFR >data. Since this would also end your TCP stream, I would expect a TSIG >over the unauthenticated remainder of the AXFR data. Then you have both >the data and TSIG on it. > >You have to wait anyway, because you have to publish the new serial >number in one atomic publication. So, the AXFR is going to sit >somewhere in any case until it is complete. That place it can also wait >until it is properly authenticated. > >What I mean to say is, this TSIG problem is not there. > >Best regards, > Wouter > >Edward Lewis wrote: >> Expanding more on the suggestion to restrict TSIG for AXFR to each >> message (as opposed to not): >> >> - During the development of DNSSEC, there was once an AXFR signature. It >> came at the conclusion of the transfer and was cognizant of the order of >> the records. During early prototyping, it proved to be too much of a >> pain, further, it was redundant to the information in the NXT and NXT >> signatures. >> >> The TSIG spec is not exactly the same. My first concern about using one >> TSIG for multiple (or all) the messages in an AXFR response is >> reordering - but AXFR has to be in (MUST) TCP or (theoretically) any >> stream-oriented protocol. >> >> TSIG only looks at messages, not the data inside, as did the AXFR >> signatures. Don't know what that means significance-wise. >> >> - To me the issue is whether we want AXFR to odd-ball the TSIG spec by >> doing one message per TSIG or have to put up with the overhead of having >> to hold back a pool (FIFO buffer) of messages until the TSIG appears for >> the check. >> >> At 13:46 -0500 1/13/09, Edward Lewis wrote: >>> I don't think mixing and matching would work - the TSIG respondent >>> uses the key named by the TSIG requestor. The respondent does not >>> know what key the requestor has (or still has). >>> >>> I'm neutral on the other issue - AXFR could say one each per message >>> or stay as "lax" as the TSIG spec. What do others say? >>> >>> At 13:36 -0500 1/13/09, Michael StJohns wrote: >>>> Isn't it a true statement that TSIG (2845) sets minimum requirements >>>> (e.g. at least one TSIG per 100), but that AXFR clarify can specify >>>> more stringent requirements - (e.g. a TSIG per message)? >>>> >>>> One of the processing issues here is that you must wait until you see >>>> a TSIG before committing AXFR changes. From a simplicity POV placing >>>> a TSIG in each message may be the right approach. >>>> >>>> On the other hand, it may make sense to weaken 2845 and only provide >>>> a TSIG in the last message before closing an AXFR session within a >>>> TCP session. >>>> >>>> And can you mix and match TSIG signers (e.g. different key ids in the >>>> TSIG record) during an update session? >>>> >>>> So I don't think its as simple as removing the quoted text. >>>> >>>> Mike >>>> >>>> >>>> At 09:13 AM 1/12/2009, Edward Lewis wrote: >>>>> Thanks for pointing that out. >>>>> >>>>> At 17:38 +0200 1/10/09, Andreas Gustafsson wrote: >>>>>> draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6): >>>>>> >>>>>> Note that TSIG and SIG(0), if in use, will treat each individual >>>>>> AXFR response message within a session as a unit of data. >>>>>> That is, >>>>>> each message will have a TSIG or SIG(0) (if in use) and the >>>>>> cryptographic check will cover just that message. >>>>>> >>>>>> That's not what the TSIG specification says. According to RFC2845 >>>>>> section 4.4, the TSIG does not have to be present on every message >>>>>> (only at least every 100th message), and does not cover just that >>>>>> message but the "Prior Digest", every unsigned message since the last >>>>>> TSIG, and the "TSIG Timers". >>>>>> >>>>>> I suggest removing the paragraph containing the quoted text. >>>>>> -- >>>>>> Andreas Gustafsson, gson@araneus.fi >>>>> >>>>> -- >>>>> >>>>>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>>> >>>>> Edward Lewis >>>>> NeuStar You can leave a voice message at >>>>> +1-571-434-5468 >>>>> >>>>> Never confuse activity with progress. Activity pays more. >>>>> >>>>> -- >>>>> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>>>> the word 'unsubscribe' in a single line as the message text body. >>>>> archive: >>> >>> -- >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> >>> Edward Lewis >>> NeuStar You can leave a voice message at >>> +1-571-434-5468 >>> >>> Never confuse activity with progress. Activity pays more. >>> >>> -- >>> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>> the word 'unsubscribe' in a single line as the message text body. >>> archive: >> > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > >iEYEARECAAYFAkltpz0ACgkQkDLqNwOhpPiTzgCeKiy9qeK/HyQIO99D6r0yNIaF >Z0kAoJakeRF7Xuc9EzQJ9u1L3UHsPzRj >=3NcF >-----END PGP SIGNATURE----- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 07:35: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 49C4B3A6878; Wed, 14 Jan 2009 07:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 xvtvciIth914; Wed, 14 Jan 2009 07:35:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E24B3A63CB; Wed, 14 Jan 2009 07:35:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN7fL-0007qt-23 for namedroppers-data0@psg.com; Wed, 14 Jan 2009 15:28:23 +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 1LN7fE-0007qE-S0 for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 15:28:19 +0000 Received: from [10.31.201.29] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0EFSAP9037476; Wed, 14 Jan 2009 10:28:11 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 14 Jan 2009 10:28:08 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] question on "SHA-2" 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: Referring to http://tools.ietf.org/id/draft-ietf-dnsext-dnssec-rsasha256-10.txt In recent weeks I have seen buzzword articles talking about "SHA-2" and "SHA-256" and began to wonder if the two are one in the same. According to this passage early in the draft: # To refer to both SHA-256 and SHA-512, this document will use the name # SHA-2. This is done to improve readability. When a part of text is (I was originally going to ask: What's the difference between SHA-256 and SHA-2 and please don't say "56?") I wondered how commom place this is because I'm against making DNS or DNSSEC-centric definitions that conflict with the outside world. Looking up in Wikipedia: # The SHA-2 family uses an identical algorithm with a variable key size # which is distinguished as SHA-224, SHA-256, SHA-384, and SHA-512. I'd be more comfortable if we complied with that terminology, and then said "but DNS we don't do 224 or 384. I'd also like there to be some more fluff describing the naming convention of the SHA-s, or, just a reference to the naming convention (I don't suppose we can use Wiki URLs). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 07: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 AF6433A6B71; Wed, 14 Jan 2009 07:47:06 -0800 (PST) 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 yXm4cwVfArN9; Wed, 14 Jan 2009 07:47:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9BC523A6B7C; Wed, 14 Jan 2009 07:46:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN7pu-0008ia-P1 for namedroppers-data0@psg.com; Wed, 14 Jan 2009 15:39:18 +0000 Received: from [83.246.72.252] (helo=gurgel.gson.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN7ph-0008h4-PE for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 15:39:12 +0000 Received: from guava.gson.org (a91-152-76-252.elisa-laajakaista.fi [91.152.76.252]) by gurgel.gson.org (Postfix) with ESMTP id DB9FD7C40C; Wed, 14 Jan 2009 15:38:55 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 8648575F38; Wed, 14 Jan 2009 17:38:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18798.1807.539406.77537@guava.gson.org> Date: Wed, 14 Jan 2009 17:38:55 +0200 To: Edward Lewis Cc: "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies In-Reply-To: References: <18792.49369.190133.315605@guava.gson.org> <496DA73D.8090804@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: Edward Lewis wrote: > I think there maybe some confusion over "commit." Yes, only after > the "ZIT" completes and is whole is it committed to being the "ZIP." > (T/P = Transfer/Published from an earlier email.) But, when AXFR > messages are being received, the ZIT is being built up in memory - > that is the commit in question, e.g., how many messages do I have to > hold before editing the ZIT copy? One. You update the digest state and the "ZIT" with each message as it arrives and then you can immediately throw the message away. TSIG isn't broken. Can we please stop fiddling with it and focus on AXFR? -- 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 Wed Jan 14 08:02: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 5AA6128C171; Wed, 14 Jan 2009 08:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 jCQTO5xCppD6; Wed, 14 Jan 2009 08:02:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 81D0728C129; Wed, 14 Jan 2009 08:02:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN82G-0009vy-83 for namedroppers-data0@psg.com; Wed, 14 Jan 2009 15:52:04 +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 1LN823-0009tp-Af for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 15:52:00 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n0EFkd05012562; Wed, 14 Jan 2009 15:46:39 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n0EFkds8012561; Wed, 14 Jan 2009 15:46:39 GMT Date: Wed, 14 Jan 2009 15:46:39 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Cc: "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies Message-ID: <20090114154639.GA12525@vacation.karoshi.com.> References: <18792.49369.190133.315605@guava.gson.org> <496DA73D.8090804@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: packets/bits "in-flight" are not commited. even when they have arrived at the destination (but are still held up in customs). (you can hold zero-millions+ messages - i don't realy care) Only when the canonical instance has been modified is the commit done. There still might be a lag to push out the updates to the visible servers. --bill On Wed, Jan 14, 2009 at 09:48:57AM -0500, Edward Lewis wrote: > I think there maybe some confusion over "commit." Yes, only after > the "ZIT" completes and is whole is it committed to being the "ZIP." > (T/P = Transfer/Published from an earlier email.) But, when AXFR > messages are being received, the ZIT is being built up in memory - > that is the commit in question, e.g., how many messages do I have to > hold before editing the ZIT copy? > > At 9:50 +0100 1/14/09, W.C.A. Wijngaards wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >Hi Ed, > > > >You cannot commit AXFR changes until you have obtained all of the AXFR > >data. Since this would also end your TCP stream, I would expect a TSIG > >over the unauthenticated remainder of the AXFR data. Then you have both > >the data and TSIG on it. > > > >You have to wait anyway, because you have to publish the new serial > >number in one atomic publication. So, the AXFR is going to sit > >somewhere in any case until it is complete. That place it can also wait > >until it is properly authenticated. > > > >What I mean to say is, this TSIG problem is not there. > > > >Best regards, > > Wouter > > > >Edward Lewis wrote: > >> Expanding more on the suggestion to restrict TSIG for AXFR to each > >> message (as opposed to not): > >> > >> - During the development of DNSSEC, there was once an AXFR signature. It > >> came at the conclusion of the transfer and was cognizant of the order of > >> the records. During early prototyping, it proved to be too much of a > >> pain, further, it was redundant to the information in the NXT and NXT > >> signatures. > >> > >> The TSIG spec is not exactly the same. My first concern about using one > >> TSIG for multiple (or all) the messages in an AXFR response is > >> reordering - but AXFR has to be in (MUST) TCP or (theoretically) any > >> stream-oriented protocol. > >> > >> TSIG only looks at messages, not the data inside, as did the AXFR > >> signatures. Don't know what that means significance-wise. > >> > >> - To me the issue is whether we want AXFR to odd-ball the TSIG spec by > >> doing one message per TSIG or have to put up with the overhead of having > >> to hold back a pool (FIFO buffer) of messages until the TSIG appears for > >> the check. > >> > >> At 13:46 -0500 1/13/09, Edward Lewis wrote: > >>> I don't think mixing and matching would work - the TSIG respondent > >>> uses the key named by the TSIG requestor. The respondent does not > >>> know what key the requestor has (or still has). > >>> > >>> I'm neutral on the other issue - AXFR could say one each per message > >>> or stay as "lax" as the TSIG spec. What do others say? > >>> > >>> At 13:36 -0500 1/13/09, Michael StJohns wrote: > >>>> Isn't it a true statement that TSIG (2845) sets minimum requirements > >>>> (e.g. at least one TSIG per 100), but that AXFR clarify can specify > >>>> more stringent requirements - (e.g. a TSIG per message)? > >>>> > >>>> One of the processing issues here is that you must wait until you see > >>>> a TSIG before committing AXFR changes. From a simplicity POV placing > >>>> a TSIG in each message may be the right approach. > >>>> > >>>> On the other hand, it may make sense to weaken 2845 and only provide > >>>> a TSIG in the last message before closing an AXFR session within a > >>>> TCP session. > >>>> > >>>> And can you mix and match TSIG signers (e.g. different key ids in the > >>>> TSIG record) during an update session? > >>>> > >>>> So I don't think its as simple as removing the quoted text. > >>>> > >>>> Mike > >>>> > >>>> > >>>> At 09:13 AM 1/12/2009, Edward Lewis wrote: > >>>>> Thanks for pointing that out. > >>>>> > >>>>> At 17:38 +0200 1/10/09, Andreas Gustafsson wrote: > >>>>>> draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6): > >>>>>> > >>>>>> Note that TSIG and SIG(0), if in use, will treat each individual > >>>>>> AXFR response message within a session as a unit of data. > >>>>>> That is, > >>>>>> each message will have a TSIG or SIG(0) (if in use) and the > >>>>>> cryptographic check will cover just that message. > >>>>>> > >>>>>> That's not what the TSIG specification says. According to RFC2845 > >>>>>> section 4.4, the TSIG does not have to be present on every message > >>>>>> (only at least every 100th message), and does not cover just that > >>>>>> message but the "Prior Digest", every unsigned message since the last > >>>>>> TSIG, and the "TSIG Timers". > >>>>>> > >>>>>> I suggest removing the paragraph containing the quoted text. > >>>>>> -- > >>>>>> Andreas Gustafsson, gson@araneus.fi > >>>>> > >>>>> -- > >>>>> > >>>>>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >>>>> > >>>>> Edward Lewis > >>>>> NeuStar You can leave a voice message at > >>>>> +1-571-434-5468 > >>>>> > >>>>> Never confuse activity with progress. Activity pays more. > >>>>> > >>>>> -- > >>>>> to unsubscribe send a message to namedroppers-request@ops.ietf.org > >>>>> with > >>>>> the word 'unsubscribe' in a single line as the message text body. > >>>>> archive: > >>> > >>> -- > >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >>> > >>> Edward Lewis > >>> NeuStar You can leave a voice message at > >>> +1-571-434-5468 > >>> > >>> Never confuse activity with progress. Activity pays more. > >>> > >>> -- > >>> to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >>> the word 'unsubscribe' in a single line as the message text body. > >>> archive: > >> > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.9 (GNU/Linux) > >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > > >iEYEARECAAYFAkltpz0ACgkQkDLqNwOhpPiTzgCeKiy9qeK/HyQIO99D6r0yNIaF > >Z0kAoJakeRF7Xuc9EzQJ9u1L3UHsPzRj > >=3NcF > >-----END PGP SIGNATURE----- > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Never confuse activity with progress. Activity pays more. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 08:09: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 A0D4028C18A; Wed, 14 Jan 2009 08:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 VjFcrmbwZKOg; Wed, 14 Jan 2009 08:09:58 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA1373A6878; Wed, 14 Jan 2009 08:09:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN8Da-000Awu-SI for namedroppers-data0@psg.com; Wed, 14 Jan 2009 16:03: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 1LN8DO-000AvS-Nd for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 16:03:40 +0000 Received: from [10.31.201.29] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0EG3R95037860; Wed, 14 Jan 2009 11:03:28 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Wed, 14 Jan 2009 11:00:19 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] http://tools.ietf.org/id/draft-ietf-dnsext-dnsproxy-01.txt 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: From reading this draft I get the impression that proxies should "do nothing" to the DNS messages they see. But apparently the proxies are there for a reason. So, my question is, what are proxies "allowed" to do. If the proxy's job is to lift the DNS message from one subnet to another (up and over a router), then the proxy ought to not touch anything in the DNS message (endangering the TSIG for example). The proxy can change what's in the UDP header (assuming just UDP for now), like the source address but the port number, if randomized, has to be somewhat free to change. Perhaps the proxy does it's own randomization. If the proxy's job is to pass only clean DNS messages, then there's a lot of education to do, helping define what "clean" is. The odd thing to me is that the definition of a "clean" message is already scattered in public document, without some specific idea of what is usually mucked up a recommendation or reinforcement is hard to do. If the proxy's job is to protect the network from incoming bad DNS packets, including stateful proxies which are essentially recursive caches outright, these have to be a lot smarter and know the tricks of the protocol. These would be the most invasive (least transparent). I'm saying this because the introduction is a bit too short or loose to set the problem domain in my mind. Perhaps examples of "bugs" (without naming vendors or course) would help. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 08:17: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 7278E28C1A4; Wed, 14 Jan 2009 08:17:49 -0800 (PST) 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 S-FcBViJhDTi; Wed, 14 Jan 2009 08:17:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 243E328C1BB; Wed, 14 Jan 2009 08:17:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN8GJ-000BEw-27 for namedroppers-data0@psg.com; Wed, 14 Jan 2009 16:06:35 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN8G7-000BDq-Mw for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 16:06:31 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n0EG6H7g009003 for ; Wed, 14 Jan 2009 11:06:18 -0500 Message-ID: <496E0D79.4030304@nist.gov> Date: Wed, 14 Jan 2009 11:06:17 -0500 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] question on "SHA-2" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Edward Lewis wrote: > Referring to > http://tools.ietf.org/id/draft-ietf-dnsext-dnssec-rsasha256-10.txt > > In recent weeks I have seen buzzword articles talking about "SHA-2" and > "SHA-256" and began to wonder if the two are one in the same. According > to this passage early in the draft: > > # To refer to both SHA-256 and SHA-512, this document will use the name > # SHA-2. This is done to improve readability. When a part of text is > > (I was originally going to ask: What's the difference between SHA-256 > and SHA-2 and please don't say "56?") 254 actually. :) > > I wondered how commom place this is because I'm against making DNS or > DNSSEC-centric definitions that conflict with the outside world. Looking > up in Wikipedia: > > # The SHA-2 family uses an identical algorithm with a variable key size > # which is distinguished as SHA-224, SHA-256, SHA-384, and SHA-512. > That is the commonly understood definition, but SHA-2 hasn't been "officially" defined that way (FIPS-180 doesn't use the term SHA-2 for example), just that those hash functions have been lumped together under a common umbrella term. It's sometimes referred to as the "SHA-2 family" in some NIST comments: http://csrc.nist.gov/groups/ST/hash/statement.html Scott -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 08:52: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 A2A0428C1DC; Wed, 14 Jan 2009 08:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 ATBp3rblTbwq; Wed, 14 Jan 2009 08:52:35 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B39A328C1D2; Wed, 14 Jan 2009 08:52:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN8rK-000Erb-8q for namedroppers-data0@psg.com; Wed, 14 Jan 2009 16:44:50 +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 1LN8rC-000EqV-6K for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 16:44:44 +0000 Received: from [10.31.201.29] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n0EGiRIp038254; Wed, 14 Jan 2009 11:44:27 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <496E0D79.4030304@nist.gov> References: <496E0D79.4030304@nist.gov> Date: Wed, 14 Jan 2009 11:44:25 -0500 To: Scott Rose From: Edward Lewis Subject: Re: [dnsext] question on "SHA-2" 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 11:06 -0500 1/14/09, Scott Rose wrote: >254 actually. :) Funny. Ha. >That is the commonly understood definition, but SHA-2 hasn't been >"officially" defined that way (FIPS-180 doesn't use the term SHA-2 for >example), just that those hash functions have been lumped together under >a common umbrella term. It's sometimes referred to as the "SHA-2 >family" in some NIST comments: >http://csrc.nist.gov/groups/ST/hash/statement.html I know my comment is an annoying nit, but in the spirit of still trying to explain that "TSIG" neither covers a transaction nor is a signature (related to the misnaming of that mechanism which wasn't caught until the Security Area AD voiced a mild objection[1]), and in the more general rule of not defining non-DNS terms, my suggestion is that the document include what Scott typed here. And include any reference-able documents to show that the terminology is "not invented here." [1] I wasn't ringside for that, but, if he didn't raise a mild objection, I doubt the name would have stuck. I believe it was Stephen Kent who objected - he was once an AD and may or may not have been the sitting one at the time. My memory is hazy on this - maybe someone ringside can fill in. If there's any truth to my hazy memory. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 09:01: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 8FE2428C23D; Wed, 14 Jan 2009 09:01:25 -0800 (PST) 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 8LVVwl264cqK; Wed, 14 Jan 2009 09:01:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AACAD28C1DB; Wed, 14 Jan 2009 09:01:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN8zV-000Fcd-R2 for namedroppers-data0@psg.com; Wed, 14 Jan 2009 16:53:17 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN8zL-000Fa6-Td for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 16:53:14 +0000 Received: from 98-140.antd.nist.gov (98-140.antd.nist.gov [129.6.140.98]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n0EGr9bQ015558 for ; Wed, 14 Jan 2009 11:53:09 -0500 Message-ID: <496E186C.8050408@nist.gov> Date: Wed, 14 Jan 2009 11:53:00 -0500 From: Scott Rose Organization: NIST User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] question on "SHA-2" References: <496E0D79.4030304@nist.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Edward Lewis wrote: > At 11:06 -0500 1/14/09, Scott Rose wrote: > >> 254 actually. :) > > Funny. Ha. > >> That is the commonly understood definition, but SHA-2 hasn't been >> "officially" defined that way (FIPS-180 doesn't use the term SHA-2 for >> example), just that those hash functions have been lumped together under >> a common umbrella term. It's sometimes referred to as the "SHA-2 >> family" in some NIST comments: >> http://csrc.nist.gov/groups/ST/hash/statement.html > > I know my comment is an annoying nit, but in the spirit of still trying > to explain that "TSIG" neither covers a transaction nor is a signature > (related to the misnaming of that mechanism which wasn't caught until > the Security Area AD voiced a mild objection[1]), and in the more > general rule of not defining non-DNS terms, my suggestion is that the > document include what Scott typed here. And include any reference-able > documents to show that the terminology is "not invented here." > Sounds like a good idea - given that not everyone may know that SHA-2 is just a general term and covers more than SHA-256/512. Scott > [1] I wasn't ringside for that, but, if he didn't raise a mild > objection, I doubt the name would have stuck. I believe it was Stephen > Kent who objected - he was once an AD and may or may not have been the > sitting one at the time. My memory is hazy on this - maybe someone > ringside can fill in. If there's any truth to my hazy memory. -- ---------------------------------------- Scott Rose Computer Scientist NIST ph: +1 301-975-8439 scott.rose@nist.gov http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ----------------------------------------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 09:18: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 35B2C3A69B8; Wed, 14 Jan 2009 09:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[AWL=-0.415, 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 LIZ0Cin8FWkn; Wed, 14 Jan 2009 09:18:52 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 342C73A6359; Wed, 14 Jan 2009 09:18:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN9Gz-000HDG-B5 for namedroppers-data0@psg.com; Wed, 14 Jan 2009 17:11:21 +0000 Received: from [213.154.224.43] (helo=sol.nlnetlabs.nl) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN9Gu-000HCH-7V for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 17:11:18 +0000 Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id B6637131444 for ; Wed, 14 Jan 2009 18:11:14 +0100 (CET) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id 179B6CFA0D for ; Wed, 14 Jan 2009 18:13:28 +0100 (CET) Message-ID: <496E1CB2.3080509@NLnetLabs.nl> Date: Wed, 14 Jan 2009 18:11:14 +0100 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] question on "SHA-2" References: <496E0D79.4030304@nist.gov> <496E186C.8050408@nist.gov> In-Reply-To: <496E186C.8050408@nist.gov> X-Enigmail-Version: 0.95.0 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 Scott Rose wrote: > > Edward Lewis wrote: >> At 11:06 -0500 1/14/09, Scott Rose wrote: >> >>> 254 actually. :) >> Funny. Ha. >> well, technically, if a sha-1 digest is 160 bits, and a sha-256 digest is 256, then the difference would be -64. As for -224, -384 and -512... ok i'll stop now >> I know my comment is an annoying nit, but in the spirit of still trying >> to explain that "TSIG" neither covers a transaction nor is a signature >> (related to the misnaming of that mechanism which wasn't caught until >> the Security Area AD voiced a mild objection[1]), and in the more >> general rule of not defining non-DNS terms, my suggestion is that the >> document include what Scott typed here. And include any reference-able >> documents to show that the terminology is "not invented here." >> > > Sounds like a good idea - given that not everyone may know that SHA-2 is > just a general term and covers more than SHA-256/512. > Ok, if nobody objects, i'll add your text (perhaps slightly modified) to the next final draft. Now quit bringing up stuff ;) Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkluHLIACgkQ4nZCKsdOncW7RgCghWsxLVDIR/0z7Xqv203+ejMC L7kAoKT5nurJPn7KZs0St0q3C1nvkB1d =DarI -----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 Wed Jan 14 09: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 F0F6E3A69B8; Wed, 14 Jan 2009 09:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=-1.238, 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 Y55eaiCfBEKQ; Wed, 14 Jan 2009 09:31:46 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D04203A68D6; Wed, 14 Jan 2009 09:31:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN9UU-000IMo-CO for namedroppers-data0@psg.com; Wed, 14 Jan 2009 17:25:18 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LN9U6-000IK2-3t for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 17:25: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=LrXEtLnqNT2OAGd/UfsArueku6OFbeaEJ8jkV4S+bR9J0hf14nIpPU+l 6W4O1Bnaw1Lwz/7UqtpZNSxuy2yjAM0+Rt2QB261KcqEyPih9500zxAZR 4emQfrqQ9Q/yzm9; 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=1231953894; x=1263489894; 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]=20http://tools.ietf.org/id/draft-ietf-dnsext-dnsproxy -01.txt|Date:=20Wed,=2014=20Jan=202009=2017:24:46=20+0000 |Message-ID:=20|To:=20Edward=20Lewis=20< Ed.Lewis@neustar.biz>|Cc:=20namedroppers@ops.ietf.org |MIME-Version:=201.0|In-Reply-To:=20|References:=20; bh=hPV9uQexMsA/gdDQFqOq/y393fK+t4K+XouqqRY5DBc=; b=tC+P3Iw7DOjNJhOxqazdI5u0ZsBlTcfVQsdiHNk+DbtiUwKpfjR0YbAY hwhaLjONFyfwsobXSLfVv64pvyUwdV8XvlLfL/Hgvi2gyTiC6HDSZvI9M Z9Eejz3zMsV0MUf; X-IronPort-AV: E=Sophos;i="4.37,263,1231113600"; d="scan'208";a="7876706" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 14 Jan 2009 17:24:48 +0000 In-Reply-To: References: To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] http://tools.ietf.org/id/draft-ietf-dnsext-dnsproxy-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 14 Jan 2009 17:24:46 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 14/01/2009 05:24:47 PM, Serialize complete at 14/01/2009 05:24:47 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Ed, Firstly - thanks for reviewing the draft! > From reading this draft I get the impression that proxies should "do > nothing" to the DNS messages they see. But apparently the proxies > are there for a reason. So, my question is, what are proxies > "allowed" to do. To quote the draft: "The role of the proxy should therefore be no more and no less than to receive DNS requests from clients on the LAN side, forward those verbatim to one of the known upstream recursive resolvers on the WAN side, and ensure that the whole response is returned verbatim to the original client." > If the proxy's job is to lift the DNS message from one subnet to > another (up and over a router), then the proxy ought to not touch > anything in the DNS message (endangering the TSIG for example). The > proxy can change what's in the UDP header (assuming just UDP for > now), like the source address but the port number, if randomized, has > to be somewhat free to change. Perhaps the proxy does it's own > randomization. Yes, the proxy's job is to "lift the DNS message", as you put it. The vast majority of consumers rely on their broadband gateways to provide *all* network settings in a "plug and play" manner via DHCP. However at boot-up most routers don't know what the upstream resolver addresses are going to be. The "safe" option therefore for the vendors is for them to put the router's own LAN address in the DHCP offer, and then proxy the packets once they've learned the upstream settings via DHCP / PPP-IPCP, etc. That's where it all starts to go wrong, since their code for proxying the packets (especially the responses) leaves much to be desired. > If the proxy's job is to pass only clean DNS messages, then there's a > lot of education to do, helping define what "clean" is. The odd > thing to me is that the definition of a "clean" message is already > scattered in public document, without some specific idea of what is > usually mucked up a recommendation or reinforcement is hard to do. Yes, that's partly what I'm trying to do with this draft - provide a consolidated list of what implementers need to know to be clean w.r.t. current standards. > If the proxy's job is to protect the network from incoming bad DNS > packets, including stateful proxies which are essentially recursive > caches outright, these have to be a lot smarter and know the tricks > of the protocol. Yes. But protocols evolve, and vendors are prone to obsoleting products and ceasing firmware updates :( > These would be the most invasive (least transparent). Indeed. > I'm saying this because the introduction is a bit too short or loose > to set the problem domain in my mind. Perhaps examples of "bugs" > (without naming vendors or course) would help. Look for the word "observed" in the draft. Most instances describe bugs found whilst doing the testing for SAC035. There is more detail in SAC035 itself, but it's not (currently) my intent to provide more detail within the draft itself. cheers, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- to unsubscribe send a message to namedroppers-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 Jan 14 11:52: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 F26BD3A686A; Wed, 14 Jan 2009 11:52:02 -0800 (PST) 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 j7zhpumJ9kan; Wed, 14 Jan 2009 11:52:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34B9B3A6A33; Wed, 14 Jan 2009 11:52:01 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNBcH-0002bf-28 for namedroppers-data0@psg.com; Wed, 14 Jan 2009 19:41:29 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNBcB-0002aZ-Ri for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 19:41:26 +0000 X-IronPort-AV: E=Sophos;i="4.37,263,1231113600"; d="scan'208";a="33802241" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Jan 2009 19:41:20 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0EJfKXJ027478; Wed, 14 Jan 2009 14:41:20 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0EJfKqh003832; Wed, 14 Jan 2009 19:41:20 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jan 2009 14:41:20 -0500 Received: from [161.44.65.167] ([161.44.65.167]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jan 2009 14:41:19 -0500 Message-ID: <496E3FDF.4060204@cisco.com> Date: Wed, 14 Jan 2009 14:41:19 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Edward Lewis CC: Andreas Gustafsson , "W.C.A. Wijngaards" , namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: axfr-clarify-10 TSIG inconsistencies References: <18792.49369.190133.315605@guava.gson.org> <496DA73D.8090804@nlnetlabs.nl> <18798.1807.539406.77537@guava.gson.org> In-Reply-To: <18798.1807.539406.77537@guava.gson.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2009 19:41:20.0003 (UTC) FILETIME=[12CC2530:01C97680] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1257; t=1231962080; x=1232826080; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=joshl@cisco.com; z=From:=20Josh=20Littlefield=20 |Subject:=20Re=3A=20[dnsext]=20Re=3A=20axfr-clarify-10=20TS IG=20inconsistencies |Sender:=20 |To:=20Edward=20Lewis=20; bh=/sVAPgRi+ooEuH38g7DXR/zxgOO1h3w/pu9WPFEQqWM=; b=RuEE1CI7YhRVqc3riyyoouigYGP//yHQlD0r4LvMGWn+EStEmzp6Jh+5mG 8/QxMAizSpDr3ZzH5ZzVNgeB5gfIRF21aPfJ7Dekx9H3Z8H8OBicqBW/yDZ9 1ovpO6mwFD; Authentication-Results: rtp-dkim-2; header.From=joshl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Andreas Gustafsson wrote: > Edward Lewis wrote: > >> I think there maybe some confusion over "commit." Yes, only after >> the "ZIT" completes and is whole is it committed to being the "ZIP." >> (T/P = Transfer/Published from an earlier email.) But, when AXFR >> messages are being received, the ZIT is being built up in memory - >> that is the commit in question, e.g., how many messages do I have to >> hold before editing the ZIT copy? >> > > One. You update the digest state and the "ZIT" with each message as > it arrives and then you can immediately throw the message away. > > TSIG isn't broken. Can we please stop fiddling with it and focus on > AXFR? > Yes, please! AXFR-clarify does not have the change anything about TSIG. Periodic TSIGs are fine, and create no additional "message holding" requirements on the xfer recipient. At the TSIG level, the intervening packets just feed into the HMAC state. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-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 Jan 14 15:12: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 84C1828C1EE; Wed, 14 Jan 2009 15:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_43=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 IiiljTycCtGf; Wed, 14 Jan 2009 15:12:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 697E828C1E6; Wed, 14 Jan 2009 15:12:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNEmF-000FZF-Dn for namedroppers-data0@psg.com; Wed, 14 Jan 2009 23:03:59 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNEm5-000FYd-RA for namedroppers@ops.ietf.org; Wed, 14 Jan 2009 23:03:55 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id EA4FC114028 for ; Wed, 14 Jan 2009 23:03:41 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) 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 5DB6DE60C1 for ; Wed, 14 Jan 2009 23:03:41 +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 n0EN3cHD008118 for ; Thu, 15 Jan 2009 10:03:38 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200901142303.n0EN3cHD008118@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt In-reply-to: Your message of "Wed, 14 Jan 2009 10:07:31 BST." <496DAB53.1020408@NLnetLabs.nl> Date: Thu, 15 Jan 2009 10:03:38 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <496DAB53.1020408@NLnetLabs.nl>, Jelte Jansen writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > W.C.A. Wijngaards wrote: > > Wes Hardaker wrote: > >> I have also read the diff and like the new version but with one > >> question: > > > >> 5.2.2. NSEC3 in Validators > > > >> A DNSSEC validator that implements RSA/SHA2 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/SHA256 or RSA/ > >> SHA512 as signed with an unknown algorithm, and thus as insecure. > > > >> Shouldn't that be phrased in a way that allows understanding one or the > >> other of NSEC vs NSEC3? Right now it states that if you don't > >> understand either you can't validate a zone that you do understand the > >> contents of. IE, if you don't handle NSEC3 you must treat NSEC3 zones > >> as insecure but can still treat NSEC zones as secure. That's what I > >> thought the consensus led to. > > > > Hi Wes, > > > > I also think this is where consensus led. I think the draft describes > > it. Treating NSEC3 zones as insecure is one way of 'handling' NSEC3. > > > > I think using 'either' in conjunction with 'not' is a recipe for confusion. T > hat > is why i've removed at least that sentence from the draft text. > > And I think that's what's happening here again; Wes thinks consensus leads to > the scenario where the validator will verify the zone if it contains the NSEC > type you understand. Please correct me if i'm wrong. > > Wouter (and me as well, for that matter) thinks consensus leads to 'don't ver > ify > the zone if you don't know NSEC3, because you cannot know beforehand whether > it > will be used'). > > So maybe we should have an old school consensus call. > > I think the current text describes the latter clearly. If not, please suggest > text. Without the word 'either' ;) > > > and just to recap the argument that made me favour the don't-do-it scenario; > in > that case you would get a positive-only scenario if you don't understand NSEC > 3. > For the 'current' zone and all those beneath it... Which for me would probabl > y > be a reason not to deploy sha2 at all in my zones. > The table below documements when a zone is to be treated as secure (S) or insecure (I) depending apon which algorithms are supported by the validator. NSEC ONLY NSEC3 ONLY NSEC + NSEC3 RSAMD5 S I S DSA S I S RSASHA1 S I S NSEC3DSA I I S NSEC3RSASHA1 I I S RSASHA256 I I S RSASHA512 I I S The table below documents which zones that can be served by a authortative server that understand the following algorithms. NSEC ONLY NSEC3 ONLY NSEC + NSEC3 RSAMD5/NSEC Y N Y DSA/NSEC Y N Y RSASHA1/NSEC Y N Y NSEC3DSA/NSEC Y N Y NSEC3DSA/NSEC3 N Y Y NSEC3RSASHA1/NSEC Y N Y NSEC3RSASHA1/NSEC3 N Y Y RSASHA256/NSEC Y N Y RSASHA256/NSEC3 N Y Y RSASHA512/NSEC Y N Y RSASHA512/NSEC3 N Y Y Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 20:54: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 6771C28C1CD; Wed, 14 Jan 2009 20:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.012 X-Spam-Level: X-Spam-Status: No, score=-102.012 tagged_above=-999 required=5 tests=[AWL=0.588, 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 sC-p27gIRq3o; Wed, 14 Jan 2009 20:54:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 94B7C3A688A; Wed, 14 Jan 2009 20:54:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNK6A-000JRk-3l for namedroppers-data0@psg.com; Thu, 15 Jan 2009 04:44:54 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNK64-000JRN-N1 for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 04:44:51 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 216323A688A; Wed, 14 Jan 2009 20:45:01 -0800 (PST) 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-bis-updates-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090115044502.216323A688A@core3.amsl.com> Date: Wed, 14 Jan 2009 20:45:02 -0800 (PST) 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 : Clarifications and Implementation Notes for DNSSECbis Author(s) : S. Weiler, D. Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-08.txt Pages : 12 Date : 2009-01-14 This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-bis-updates-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-14203200.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 Jan 14 22:48: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 888473A6984; Wed, 14 Jan 2009 22:48:53 -0800 (PST) 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 TGPBXe+bYRo0; Wed, 14 Jan 2009 22:48:52 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F2C83A6830; Wed, 14 Jan 2009 22:48:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNLuA-00027N-Jq for namedroppers-data0@psg.com; Thu, 15 Jan 2009 06:40:38 +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 1LNLu5-00026y-8w for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 06:40:35 +0000 Received: from crankycanuck.ca (72-255-114-85.client.stsn.net [72.255.114.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7C2022FE9830 for ; Thu, 15 Jan 2009 06:40:29 +0000 (UTC) Date: Thu, 15 Jan 2009 01:40:26 -0500 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] More on RFC 5378 Message-ID: <20090115064025.GA81748@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, Russ Housley has asked that WG Chairs apprise the WG of the situation, and I can think of no better way than to forward his message and the original message (see below) unmolested. Olafur and I already brought this topic to the WG's attention in a previous message. Now as then, our attitude is that you must understand for yourself the agreements into which you are entering by virtue of participation; we are not competent to provide you with legal advice. I again remind everyone that this WG is not the place to discuss whether the rules under discussion are sensible or ought to be maintained. That discussion is off-topic for this list. I note that there is an open thread on the topic on the IETF general list, so if you have something to say on the topic, that's the list on which to pursue it. Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. --DocE+STaALJfprDB Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mail.ietf.org ([64.170.98.32] verified) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 17332721 for ajs@shinkuro.com; Wed, 14 Jan 2009 09:23:33 -0700 Received-SPF: pass receiver=execdsl.com; client-ip=64.170.98.32; envelope-from=wgchairs-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1A628C1A4; Wed, 14 Jan 2009 08:23:46 -0800 (PST) X-Original-To: wgchairs@core3.amsl.com Delivered-To: wgchairs@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1BF73A6833 for ; Wed, 14 Jan 2009 08:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, 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 D4KZCiJ4DjD8 for ; Wed, 14 Jan 2009 08:23:44 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 8B60C3A63CB for ; Wed, 14 Jan 2009 08:23:44 -0800 (PST) Received: (qmail 27912 invoked by uid 0); 14 Jan 2009 16:23:26 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 14 Jan 2009 16:23:26 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 Jan 2009 11:00:05 -0500 To: wgchairs@ietf.org From: Russ Housley Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem Message-Id: <20090114162344.8B60C3A63CB@core3.amsl.com> X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: wgchairs-bounces@ietf.org Errors-To: wgchairs-bounces@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 WG Chairs: Please make sure that your WG, and especially your document authors, are aware of this situation. Please follow the discussion on the IETF Discussion list, and keep the WG informed about the way forward as it develops. Thanks, Russ > From: "Ed Juskevicius" > To: "'IETF Discussion'" , , > , , , > > Date: Thu, 8 Jan 2009 16:43:50 -0500 > Cc: 'Trustees' > Subject: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and > comments on a proposed Work-Around to the Pre-5378 Problem > > The purpose of this message is twofold: > > 1) To summarize the issues that some members of our community > have experienced since the publication of RFC 5378 in November 2008, > and > 2) To invite community review and discussion on a potential work-around > being considered by the IETF Trustees. > > Some I-D authors are having difficulty implementing RFC 5378. An > example of the difficulty is as follows: > > - an author wants to include pre-5378 content in a new submission > or contribution to the IETF, but > - s/he is not certain that all of the author(s) of the earlier > material have agreed to license it to the IETF Trust according > to RFC 5378. > > If an I-D author includes pre-5378 material in a new document, then s/he > must represent or warrant that all of the authors who created the > pre-5378 material have granted rights for that material to the IETF Trust. > If s/he cannot make this assertion, then s/he has a problem. > > This situation has halted the progression of some Internet-Drafts and > interrupted the publication of some RFCs. The Trustees of the IETF Trust > are investigating ways to implement a temporary work-around so that IETF > work can continue to progress. A permanent solution to this "pre-5378 > problem" may require an update to RFC 5378, for example new work by the > community to create a 5378-bis document. > > The remainder of this message provides an outline of the temporary work- > around being considered by the Trustees. > > RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the > authority to develop legend text for authors to use in situations where > they wish to limit the granting of rights to modify and prepare > derivatives of the documents they submit. The Trustees used this > authority in 2008 to develop and adopt the current "Legal Provisions > Relating to IETF Documents" which are posted at: > http://trustee.ietf.org/license-info/. > > The Trustees are now considering the creation of optional new legend text > which could be used by authors experiencing the "pre-5378 problem". > > The new legend text, if implemented, would do the following: > > a. Provide Authors and Contributors with a way to identify (to the > IETF Trust) that their contributions contain material from pre-5378 > documents for which RFC 5378 rights to modify the material outside > the IETF standards process may not have been granted, and > > b. Provide the IETF Trust and the community with a clear indication > of every document containing pre-5378 content and having the > "pre-5378 problem". > > So, how could the creation and use of some new legend text help people > work-around the pre-5378 problem? > > The proposed answer is as follows: > > 1. Anyone having a contribution with the "pre-5378" problem should add > new legend text to the contribution, to clearly flag that it includes > pre-5378 material for which all of the rights needed under RFC 5378 > may not have been granted, and > > 2. The IETF Trust will consider authors and contributors (with the > pre-5378 problem) to have met their RFC 5378 obligations if the > new legend text appears on their documents, and > > 3. Authors and contributors should only resort to adding the new > legend text to their documents (per #1) if they cannot develop > certainty that all of the author(s) of pre-5378 material in > their documents have agreed to license the pre-5378 content to > the IETF Trust according to RFC 5378. > > The proposed wording for the new legend text is now available for your > review and comments in section 6.c.iii of a draft revision to the > IETF Trust's "Legal Provisions Relating to IETF Documents" located at > http://trustee.ietf.org/policyandprocedures.html. > > Please note that the above document also contains new text in section 5.c > dealing with "License Limitations". > > If your review and feedback on this proposed work-around is positive, > then the new text may be adopted by the Trustees in early February 2009, > and then be published as an official revision to the Legal Provisions > document. If so adopted, Internet-Drafts with pre-5378 material may > advance within the Internet standards process and get published as RFCs > where otherwise qualified to do so. Unless covered by sections 6.c.i or > 6.c.ii, authors of documents in which there is no pre-5378 > material must provide a RFC 5378 license with no limitation on > modifications outside the IETF standards process. > > The IETF Trust will not grant the right to modify or prepare derivative > works of any specific RFC or other IETF Contribution outside the IETF > standards process until RFC 5378 rights pertaining to that document have > been obtained from all authors and after compliance by the IETF Trust > with RFC 5377. The Trustees will establish one or more mechanisms by > which authors of pre-5378 documents may grant RFC 5378 rights. > > The Trustees hereby invite your review, comments and suggestions on this > proposed work-around to the "pre-5378 problem". The period for this review > is 30 days. Microsoft WORD and PDF versions of the proposed revisions are > attached to this message. Copies are also available on the IETF Trust > website under the heading "DRAFT Policy and Procedures Being Developed" at: > http://trustee.ietf.org/policyandprocedures.html > > All feedback submitted before the end of February 7th will be considered by > the Trustees. A decision on whether to move forward with this proposal will > be made and communicated to you before the end of February 15th. > > Please give this your attention. > > Regards and Happy New Year ! > > Ed Juskevicius, on behalf of the IETF Trustees > edj.etc@gmail.com --DocE+STaALJfprDB-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From l.tifft@247media.com Thu Jan 15 02:53: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 784513A67D8 for ; Thu, 15 Jan 2009 02:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.819 X-Spam-Level: X-Spam-Status: No, score=-11.819 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_20=1.546, 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, RDNS_NONE=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 0STg9FWjOFSK for ; Thu, 15 Jan 2009 02:53:36 -0800 (PST) Received: from alexander-tvl.com (unknown [93.177.155.247]) by core3.amsl.com (Postfix) with SMTP id D8DA93A6407 for ; Thu, 15 Jan 2009 02:53:30 -0800 (PST) To: Subject: Re: admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115105332.D8DA93A6407@core3.amsl.com> Date: Thu, 15 Jan 2009 02:53:30 -0800 (PST)

From owner-namedroppers@ops.ietf.org Thu Jan 15 04:45: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 290BB28C11A; Thu, 15 Jan 2009 04:45:11 -0800 (PST) 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 iRcSMnyYfv-r; Thu, 15 Jan 2009 04:45:10 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EE3F3A691B; Thu, 15 Jan 2009 04:45:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNRQ4-00079E-6I for namedroppers-data0@psg.com; Thu, 15 Jan 2009 12:33:56 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNRPy-00078d-JC for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 12:33:52 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id A72EC114039; Thu, 15 Jan 2009 12:33:34 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) 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 F3F27E60BC; Thu, 15 Jan 2009 12:33:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n0FCXUq6012360; Thu, 15 Jan 2009 23:33:31 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200901151233.n0FCXUq6012360@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] http://tools.ietf.org/id/draft-ietf-dnsext-dnsproxy-01.txt In-reply-to: Your message of "Wed, 14 Jan 2009 11:00:19 CDT." Date: Thu, 15 Jan 2009 23:33:29 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message , Edward Lewis writes: > From reading this draft I get the impression that proxies should "do > nothing" to the DNS messages they see. But apparently the proxies > are there for a reason. So, my question is, what are proxies > "allowed" to do. > > If the proxy's job is to lift the DNS message from one subnet to > another (up and over a router), then the proxy ought to not touch > anything in the DNS message (endangering the TSIG for example). The > proxy can change what's in the UDP header (assuming just UDP for > now), like the source address but the port number, if randomized, has > to be somewhat free to change. Perhaps the proxy does it's own > randomization. A proxy can change the id of a message. This is actually necessary to enable proper identificatin of replies. This will not impact of TSIG as the id is explicitly excluded from the computation. > If the proxy's job is to pass only clean DNS messages, then there's a > lot of education to do, helping define what "clean" is. The odd > thing to me is that the definition of a "clean" message is already > scattered in public document, without some specific idea of what is > usually mucked up a recommendation or reinforcement is hard to do. > > If the proxy's job is to protect the network from incoming bad DNS > packets, including stateful proxies which are essentially recursive > caches outright, these have to be a lot smarter and know the tricks > of the protocol. These would be the most invasive (least > transparent). > > I'm saying this because the introduction is a bit too short or loose > to set the problem domain in my mind. Perhaps examples of "bugs" > (without naming vendors or course) would help. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Never confuse activity with progress. Activity pays more. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 04:54: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 3643A28C187; Thu, 15 Jan 2009 04:54:21 -0800 (PST) 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, 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 JNiUFhH5Vd12; Thu, 15 Jan 2009 04:54:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A96628C101; Thu, 15 Jan 2009 04:54:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNRdJ-0008Ko-98 for namedroppers-data0@psg.com; Thu, 15 Jan 2009 12:47:37 +0000 Received: from [217.147.82.63] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNRdE-0008KJ-ST for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 12:47:34 +0000 Received: from [192.168.100.39] (localhost [127.0.0.1]) by mail.avalus.com (Postfix) with ESMTP id 56E97C2DB6; Thu, 15 Jan 2009 12:47:28 +0000 (GMT) Date: Thu, 15 Jan 2009 12:48:46 +0000 From: Alex Bligh Reply-To: Alex Bligh To: Mark Andrews , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt Message-ID: <90626B51DFA87C1353B2CC67@host46.msm.che.vodafone> In-Reply-To: <200901142303.n0EN3cHD008118@drugs.dv.isc.org> References: <200901142303.n0EN3cHD008118@drugs.dv.isc.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 15 January 2009 10:03:38 +1100 Mark Andrews wrote: > The table below documements when a zone is to be treated as > secure (S) or insecure (I) depending apon which algorithms > are supported by the validator. > > NSEC ONLY NSEC3 ONLY NSEC + NSEC3 > RSAMD5 S I S > DSA S I S > RSASHA1 S I S > NSEC3DSA I I * S > NSEC3RSASHA1 I I * S > RSASHA256 I I S > RSASHA512 I I S Are the two starred entries correct? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 05:09: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 0AE6C28C200; Thu, 15 Jan 2009 05:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[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 2aQr0TQVdR3D; Thu, 15 Jan 2009 05:09:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 359DD28C117; Thu, 15 Jan 2009 05:09:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNRpm-0009W3-S7 for namedroppers-data0@psg.com; Thu, 15 Jan 2009 13:00:30 +0000 Received: from [195.54.233.68] (helo=shaun.rfc1035.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNRpa-0009Tr-Mu for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 13:00:22 +0000 Received: from [217.33.138.50] (account jim HELO [172.16.1.37]) by shaun.rfc1035.com (CommuniGate Pro SMTP 5.1.4) with ESMTPSA id 400212; Thu, 15 Jan 2009 13:00:17 +0000 Cc: namedroppers@ops.ietf.org Message-Id: From: Jim Reid To: Ray.Bellis@nominet.org.uk 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] DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 Date: Thu, 15 Jan 2009 12:59:16 +0000 References: X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jan 6, 2009, at 11:52, Ray.Bellis@nominet.org.uk wrote: > An update to this draft has been uploaded with revisions based on > comments > received so far. > Would those who volunteered to review so that this could became a WG > item > please take another look? I have reviewed the latest draft. Although it still needs some work, it's in pretty good shape. I support this draft becoming a work item for the WG. -- to unsubscribe send a message to namedroppers-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 Jan 15 06:30: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 25D6328C19D; Thu, 15 Jan 2009 06:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_43=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 prG-JgkUPNJT; Thu, 15 Jan 2009 06:29:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AF0E28C196; Thu, 15 Jan 2009 06:29:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNT7X-000GL9-4e for namedroppers-data0@psg.com; Thu, 15 Jan 2009 14:22:55 +0000 Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNT7R-000GKb-D8 for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 14:22:52 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id 00FF5114027; Thu, 15 Jan 2009 14:22:42 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) 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 6A685E60BC; Thu, 15 Jan 2009 14:22:42 +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 n0FEMdeh021420; Fri, 16 Jan 2009 01:22:40 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200901151422.n0FEMdeh021420@drugs.dv.isc.org> To: Alex Bligh Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-rsasha256-10.txt In-reply-to: Your message of "Thu, 15 Jan 2009 12:48:46 -0000." <90626B51DFA87C1353B2CC67@host46.msm.che.vodafone> Date: Fri, 16 Jan 2009 01:22:39 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: In message <90626B51DFA87C1353B2CC67@host46.msm.che.vodafone>, Alex Bligh write s: > > > --On 15 January 2009 10:03:38 +1100 Mark Andrews > wrote: > > > The table below documements when a zone is to be treated as > > secure (S) or insecure (I) depending apon which algorithms > > are supported by the validator. > > > > NSEC ONLY NSEC3 ONLY NSEC + NSEC3 > > RSAMD5 S I S > > DSA S I S > > RSASHA1 S I S > > NSEC3DSA I I * S > > NSEC3RSASHA1 I I * S > > RSASHA256 I I S > > RSASHA512 I I S > > Are the two starred entries correct? Yes. > Alex -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 06:41: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 DEB4928C1C1; Thu, 15 Jan 2009 06:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-1.100, 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 ELN2DR4Hbal2; Thu, 15 Jan 2009 06:41:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C4D1C28C1BA; Thu, 15 Jan 2009 06:41:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNTJo-000HTJ-CA for namedroppers-data0@psg.com; Thu, 15 Jan 2009 14:35:36 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNTJi-000HSh-GP for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 14:35:33 +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=12c23oAJhnUuUtudrqi7l+YyhkgIDvlQK0zBvtPOvtph68eEzPjUp/2X j/tGO8pnCXO/2SFBBcj8ShIV+ThuFDf6+6kgrbsWHzj/IFxzd7pfcvWGF aSPd/L0VbIt8eBI; 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=1232030130; x=1263566130; 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]=20DNS=20Proxy=20Implementation=20Guidelines=20-=0D=0A =20draft-ietf-dnsext-dnsproxy-01|Date:=20Thu,=2015=20Jan =202009=2014:35:28=20+0000|Message-ID:=20|To:=20Jim=20Reid=20|Cc:=20namedroppers @ops.ietf.org|MIME-Version:=201.0|In-Reply-To:=20|References:=20 =20; bh=1zx6HpO1mI1A5wSQycCVN4hLzznc+UOX5ckndm3D9Xk=; b=63NGjYyH2HxnvqjdYLREVqZy14G0n9V+iluu1GMTVeH/CYVno/2M127b UQaYS4x9qRcDjhNmT7zjZtLM9gFT1zRMD9TY3cmpPhOJ/JJl4OfXYl11V Sr4NPIAjqdkyhhA; X-IronPort-AV: E=Sophos;i="4.37,270,1231113600"; d="scan'208";a="10623732" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 15 Jan 2009 14:35:28 +0000 In-Reply-To: References:

To: Jim Reid Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS Proxy Implementation Guidelines - draft-ietf-dnsext-dnsproxy-01 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, 15 Jan 2009 14:35:28 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/01/2009 02:35:28 PM, Serialize complete at 15/01/2009 02:35:28 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: > I have reviewed the latest draft. Although it still needs some work, > it's in pretty good shape. I support this draft becoming a work item > for the WG. Jim, Thanks for reviewing the draft, although it is _already_ a WG item, as agreed in Minneapolis. I was there when you promised to Olafur that you would review it, that promise being the last of the five that the chairs needed to progress the draft. Your memory of that may be slightly hazy - we were sat in the bar at the time ;-) If you've got specific ideas or wording for the areas that you think need work, please do let me know! kind regards, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From nnnijcyw.5.stripes@aace.com Thu Jan 15 07:18: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 9416328C23F for ; Thu, 15 Jan 2009 07:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.047 X-Spam-Level: X-Spam-Status: No, score=-22.047 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_20=1.546, 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, 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_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 iMxNaRcvOXVL for ; Thu, 15 Jan 2009 07:18:23 -0800 (PST) Received: from aguasclaras.org (unknown [200.12.52.57]) by core3.amsl.com (Postfix) with SMTP id E9C9728C247 for ; Thu, 15 Jan 2009 07:18:18 -0800 (PST) To: Subject: from admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115151819.E9C9728C247@core3.amsl.com> Date: Thu, 15 Jan 2009 07:18:18 -0800 (PST)

From owner-namedroppers@ops.ietf.org Thu Jan 15 08:37: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 D078B3A67D6; Thu, 15 Jan 2009 08:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 YSQ3tIEiHIEl; Thu, 15 Jan 2009 08:37:38 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 064D53A6A3D; Thu, 15 Jan 2009 08:37:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNV38-0001ZI-Kr for namedroppers-data0@psg.com; Thu, 15 Jan 2009 16:26:30 +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 1LNV32-0001XQ-Ev for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 16:26:27 +0000 Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0FGQMHK059066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jan 2009 09:26:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 15 Jan 2009 08:26:21 -0800 To: namedroppers@ops.ietf.org From: Paul Hoffman Subject: [dnsext] Comments on draft-ietf-dnsext-dnssec-bis-updates-08 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Thank you to the authors for updating this document. A few editorial comments: - The sentence at the beginning of section 2 needs an object and some terminating punctuation (hopefully a period, but an exclamation mark might also be appropriate). - The second sentence in section 2.1 should use "because" instead of "as". "As" can be interpreted as meaning "when", which is not what is desired here. - The first sentence of section 7 (the security considerations) is now wrong, given the two additions in section 2. The first two sentences can be replaced by: This document adds two cryptographic features to the core DNSSEC protocol. It also addresses some ambiguities and omissions... --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 karolina.mierzejewska@aigcredit.pl Thu Jan 15 08:41: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 F09593A67D6 for ; Thu, 15 Jan 2009 08:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.962 X-Spam-Level: X-Spam-Status: No, score=-10.962 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=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, 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 FcOKLl6LRyuk for ; Thu, 15 Jan 2009 08:41:46 -0800 (PST) Received: from adwarecops.com (unknown [201.255.119.59]) by core3.amsl.com (Postfix) with SMTP id 3C1303A69C7 for ; Thu, 15 Jan 2009 08:41:44 -0800 (PST) To: Subject: Re: Order status 34943 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115164145.3C1303A69C7@core3.amsl.com> Date: Thu, 15 Jan 2009 08:41:44 -0800 (PST)

From owner-namedroppers@ops.ietf.org Thu Jan 15 11:00: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 9265F3A6778; Thu, 15 Jan 2009 11:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhuniFtTr1bj; Thu, 15 Jan 2009 11:00:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9AE73A6774; Thu, 15 Jan 2009 11:00:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNXKO-000EQL-QC for namedroppers-data0@psg.com; Thu, 15 Jan 2009 18:52:28 +0000 Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNXKG-000ENP-AA for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 18:52:22 +0000 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 3u1r1b0051HpZEsA5usLiX; Thu, 15 Jan 2009 18:52:20 +0000 Received: from MIKES-LAPTOM.comcast.net ([216.129.123.44]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id 3us61b00H0xb3EY8aus8en; Thu, 15 Jan 2009 18:52:17 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Jan 2009 13:52:05 -0500 To: namedroppers@ops.ietf.org From: Michael StJohns Subject: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit Cc: weiler@tislabs.com,davidb@verisign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: Message-Id: Why was the text on the upstream setting of the CD bit left out of yet another revision of this document? C.f. Name Droppers 9/15/2008, Proposed addition to dnssec-bis-updated: CD bit, Namedroppers 3/11/2008 CD bit setting from intermediate resolvers...., Namedroppers - discussions at dnsext. Etc... Mike -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 11:34: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 48C8E3A69EB; Thu, 15 Jan 2009 11:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwDMWSt3SKa7; Thu, 15 Jan 2009 11:34:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 654763A67AB; Thu, 15 Jan 2009 11:34:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNXrv-000HWn-Ef for namedroppers-data0@psg.com; Thu, 15 Jan 2009 19:27:07 +0000 Received: from [65.201.175.9] (helo=cliffie.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNXrj-000HVu-Do for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 19:27:04 +0000 Received: from [192.168.1.14] (pool-96-231-22-181.washdc.fios.verizon.net [96.231.22.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cliffie.verisignlabs.com (Postfix) with ESMTP id 8F8301366D0; Thu, 15 Jan 2009 14:26:51 -0500 (EST) Cc: namedroppers@ops.ietf.org, weiler@tislabs.com Message-Id: From: "Blacka, David" 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] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit Date: Thu, 15 Jan 2009 14:26:50 -0500 References: X-Mailer: Apple Mail (2.930.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: On Jan 15, 2009, at 1:52 PM, Michael StJohns wrote: > Why was the text on the upstream setting of the CD bit left out of > yet another revision of this document? I thought it was included. Isn't your concern addressed by section 4.7? Or did I miss something? > > C.f. Name Droppers 9/15/2008, Proposed addition to dnssec-bis- > updated: CD bit, Namedroppers 3/11/2008 CD bit setting from > intermediate resolvers...., Namedroppers - discussions at dnsext. > Etc... > > Mike > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: -- David Blacka Sr. Engineer Platform Product Development -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 12:16: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 394913A699D; Thu, 15 Jan 2009 12:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KORjCVUNUxi1; Thu, 15 Jan 2009 12:16:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C4303A6963; Thu, 15 Jan 2009 12:16:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNYRm-000KhY-1c for namedroppers-data0@psg.com; Thu, 15 Jan 2009 20:04:10 +0000 Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LNYRd-000KhD-D9 for namedroppers@ops.ietf.org; Thu, 15 Jan 2009 20:04:06 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 3uvZ1b02i1GhbT859w41WY; Thu, 15 Jan 2009 20:04:01 +0000 Received: from MIKES-LAPTOM.comcast.net ([216.129.123.44]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 3w3n1b00c0xb3EY3Tw3qA6; Thu, 15 Jan 2009 20:03:59 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Jan 2009 15:03:47 -0500 To: "Blacka, David" From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit Cc: namedroppers@ops.ietf.org,weiler@tislabs.com 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: