From dnsext-bounces@ietf.org Sun Apr 1 18:12:02 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73821F8653; Sun, 1 Apr 2012 18:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333329122; bh=yePIXC78VZUgFqpBm+R6/mpsvSnjxu83+Xk3Qqviz1k=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=BRXKucIY08fDCLYGRQYYxYeAybXUCSvemWqfBiT8l81m2gyV5rNPRwO5qTdR5bZwf nAwld2V/Q7u282Y1EUzVLwcR09L/g/xbjDnOA/YOXuga+Fog/LeMS5sqmkYiKAPm4o OkBs3epzHZJNWBP3RA+fuBJ6ddJSLwARQWRDmqbU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0B121F8653 for ; Sun, 1 Apr 2012 18:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vICXE3kaColO for ; Sun, 1 Apr 2012 18:12:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 420D521F8650 for ; Sun, 1 Apr 2012 18:12:00 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q321Busr041617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Apr 2012 18:11:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> Date: Sun, 1 Apr 2012 18:11:56 -0700 Message-Id: References: <20120326142607.26742.59731.idtracker@ietfa.amsl.com> <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> To: Scott Rose X-Mailer: Apple Mail (2.1257) Cc: DNSEXT Working Group Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org "obsolescing" makes me gag hard enough to call it a problem, not a nit. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Apr 1 18:15:58 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9C11E8085; Sun, 1 Apr 2012 18:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333329358; bh=GSkPtPD7/IaSke8JS4CNLIE+m7VGHIepdXJlKT3j8MY=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=o5/pF8zTm1vwWrJ+xGxS1QPMNxM4UXmnHCLbddZmwQyW8cS7OVikvqyq/CEPWTaPU bK6u2srlV0MQ3XbTVfFi9kDDx16n04YALh/3mG3ve7WeSdG9sW7rX0kKVKFxE7mzVw rWhRfYSYNkajUPVHn5eQ+X/oVNCREy/tsGhwRdjE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9111E8085 for ; Sun, 1 Apr 2012 18:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WugZxJYYRjmo for ; Sun, 1 Apr 2012 18:15:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 30C9521F8705 for ; Sun, 1 Apr 2012 18:15:57 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q321Fsfp041679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Apr 2012 18:15:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Sun, 1 Apr 2012 18:15:54 -0700 Message-Id: <37562023-C8FE-4EE4-A752-2F646B495BA5@vpnc.org> References: <20120327084731.30282.35216.idtracker@ietfa.amsl.com> To: Samuel Weiler X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 27, 2012, at 5:12 PM, Samuel Weiler wrote: > As I said at the microphone in Paris, I would strongly prefer to see typecode templates posted publicly in all cases. I see no need to shorten the review period beyond the current three weeks. > > Furthermore, as I pointed out on this list on 7 October, IANA seems to not be maintaining the archive of templates as requested in both RFC5395 and RFC6195. If we're are going to keep using this template system to allocate typecodes, we need that archive. Absent a commitment from IANA to maintain that archive, preferably backed up with evidence that they have populated that archive with the old templates, I would prefer to see us back out the RFC5395 changes to the typecode allocation process and revert to the RFC2929 rules. This is an issue for the IAB, who is in charge of the IETF's relationship with IANA. If IANA is not meeting a requirement of an RFC, they should be told to do so a bit more forcefully. We should not have to revert to a less descriptive registry. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Sun Apr 1 18:17:39 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC7611E80AA; Sun, 1 Apr 2012 18:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333329459; bh=JTSypdfV8ICcWxxCRzrYYmUL3yPtGoB/1UW4BCJ0t7g=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=qZME1jPqH+Pp8a2OZTXTH70/0tlMqnCXTxPxmj6H1SOMjI/UDbZsqTPtlmxus+AJE wG6ruUJO0eYDUISAUn5av7WswguDuqDxlz2Lz4Ta13nMthYSWqMMoSbzhJ9pGecMpO O8Y55DS9UhEuI8WLtlhMJ7yM7GG0ZBff6Six1frE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5520811E80AB for ; Sun, 1 Apr 2012 18:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob-ts1-RYku3 for ; Sun, 1 Apr 2012 18:17:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAC111E80AA for ; Sun, 1 Apr 2012 18:17:22 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q321HLlV041718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 1 Apr 2012 18:17:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com> Date: Sun, 1 Apr 2012 18:17:21 -0700 Message-Id: <1E10703D-4769-4089-ABE7-C23813E30D43@vpnc.org> References: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1257) Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-01 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mar 26, 2012, at 3:29 PM, RJ Atkinson wrote: > I support the idea of moving ECDSA to "Recommended". +1 --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 2 05:26:07 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84D621F884A; Mon, 2 Apr 2012 05:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333369567; bh=KX6UdE0uHj/3AJCiEmUSvXGtFxdqm2YzMxeGRDkdqIY=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=pNm9DWO2dmAcavt4UG3Uqz/SDe2+7sHoY7UQLN/PMCsMNfaQ/qnjh0V2nDajKNYdb 9adg0Sxttt+K2uvynzOvk9A2foDKLzQG3nVbVok0ByRFc7BeHPk1il184GrSJ1Qr1K Q3xeTjvbOcq4Yoa0dNW6+ZWS2GJ5OR713ocx0ehw= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3621F8848 for ; Mon, 2 Apr 2012 05:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHtr60f91zlR for ; Mon, 2 Apr 2012 05:26:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C8B1521F884A for ; Mon, 2 Apr 2012 05:26:04 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q32CQ3T0059036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Apr 2012 05:26:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Date: Mon, 2 Apr 2012 05:26:04 -0700 Message-Id: To: DNSEXT Working Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] How to reference "DNS"? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Greetings again. A reviewer of the latest TLSA protocol document in the DANE WG has asked us to add a normative reference to the DNS RFCs because implementers would need to understand some of the DNS before using TLSA. That seems fair. However, saying "go read these two antique RFCs that have been updated over a dozen times" doesn't seem all that useful. Is there a better RFC that can be pointed to for "you need to understand some DNS basics"? --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 2 06:38:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BCC21F84FA; Mon, 2 Apr 2012 06:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333373884; bh=1fDEE6ryvNmlBsgebiAdB8RXvS0xYijsFoRTTU8Q9nI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=OCqnquTq1z/MR98jJontse7LnZAfIHQDhX1PK9GVdsBgbuLoBorJvAEvJzL/szGTq xBaMDW49xUIo+4YnKq47L5nLsXA8dnCgCan82ksN9+q7zx6wxck/bncCUt3W4UkzMf 9rqAhlPRNjUAbRKrtuoVKw/WQMQeTrg4eo4n3on0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3499321F84FA for ; Mon, 2 Apr 2012 06:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogsIXa-NIJE8 for ; Mon, 2 Apr 2012 06:38:02 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id A042A21F84F4 for ; Mon, 2 Apr 2012 06:38:02 -0700 (PDT) Received: by qafi31 with SMTP id i31so2120076qaf.15 for ; Mon, 02 Apr 2012 06:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=RtCxYpJ1EO+f0n/M9JcTRvuQ2jnFHzTiGzUQi47XuYk=; b=DnH6dJF8UNdVpdzEfWwXwQvrYM9xGxnR/57exQBa96veOII5juF6ZwkEJ6Id7TBcEN Xz8lSyMQBRGCcALAM7+yqEcNlw3pl2hWzNalOCjlrARtW4ecewZ+cI9O8xlmI7B23k1z 0G3WZUSo2KCYFUTT7IRBjj+8rM9OAION5ZZgT2aYfEhXIsNfTicQlrtTTvIhs+9TZcr+ 5xNEGqmfEhSUBUuGPA7wZk7zphLe6+naPsOMtPlj+iknyPccFtN8vkXORo5FEvDSACE4 LgGgbVOi0ri89a+LrqPrgpPzrJVvSHh2ADCmt85cXyhbGg9o703Bgb10TsHJ+6iqYDCv tlIQ== Received: by 10.224.58.147 with SMTP id g19mr11086385qah.58.1333373882212; Mon, 02 Apr 2012 06:38:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.92.71 with HTTP; Mon, 2 Apr 2012 06:37:42 -0700 (PDT) In-Reply-To: References: <20120326142607.26742.59731.idtracker@ietfa.amsl.com> <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> From: Dick Franks Date: Mon, 2 Apr 2012 14:37:42 +0100 X-Google-Sender-Auth: p3c2j7vruYEZ73V8Zk_W2gnNNYI Message-ID: To: Paul Hoffman Cc: DNSEXT Working Group Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1136267324589343468==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============1136267324589343468== Content-Type: multipart/alternative; boundary=20cf3074d2489a222504bcb24c28 --20cf3074d2489a222504bcb24c28 Content-Type: text/plain; charset=UTF-8 On 2 April 2012 02:11, Paul Hoffman wrote: > "obsolescing" makes me gag hard enough to call it a problem, not a nit. Ugly; but apparently not obsolete, according to my English (EN-GB) dictionary! *obsolesce* *verb* (obsolesced, obsolescing) *intr * to become obsolete; to be going out of use. 19c. Chambers 21st Century Dictionary --20cf3074d2489a222504bcb24c28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2 April 2012 02:11, Paul Hoffman <paul.hoffman@vpnc.or= g> wrote:
"obsolescing" makes me gag hard enough to call it a problem, not = a nit.


Ugly;=C2=A0 but apparently not obsolete, ac= cording to my English (EN-GB) dictionary!

=C2=A0=C2=A0=C2=A0 obso= lesce =C2=A0 verb=C2=A0 (obsolesced, obsolescing)
=C2=A0 =C2=A0 intr=C2=A0 to become obsolete; to be going out of use.= 19c.

=C2=A0=C2=A0=C2=A0 Chambers 21st Century Dictionary
<= /div> --20cf3074d2489a222504bcb24c28-- --===============1136267324589343468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============1136267324589343468==-- From dnsext-bounces@ietf.org Mon Apr 2 06:41:49 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A989821F849D; Mon, 2 Apr 2012 06:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333374109; bh=OYTehaVaDyZ+uDLPnKifuaWv4bliqbPKXLZoqknl3YM=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=c9XHzpD0uL0bj0eAAAevh0U3ui4AoVyzIbdLZ6G9+Phw51YOKRb6N5/FGIZwetW8r vPCAftatQ85mMTI6n0KtP2BdsBwxZ0pTFWB+CpNPhbmfQ05GHX3joOdbrGabc34C7a 3BG2J95LybTMb8JRwmWrG1ZawlitSa3MPzUSJR8o= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1C21F84B2 for ; Mon, 2 Apr 2012 06:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRsdaVV9h5Fu for ; Mon, 2 Apr 2012 06:41:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A772521F849D for ; Mon, 2 Apr 2012 06:41:47 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D22911ECB41D for ; Mon, 2 Apr 2012 13:41:46 +0000 (UTC) Date: Mon, 2 Apr 2012 09:41:43 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120402134134.GA22464@mail.yitter.info> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] How to reference "DNS"? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mon, Apr 02, 2012 at 05:26:04AM -0700, Paul Hoffman wrote: > Greetings again. A reviewer of the latest TLSA protocol document in the DANE WG has asked us to add a normative reference to the DNS RFCs because implementers would need to understand some of the DNS before using TLSA. That seems fair. However, saying "go read these two antique RFCs that have been updated over a dozen times" doesn't seem all that useful. Is there a better RFC that can be pointed to for "you need to understand some DNS basics"? > No, and there is no agreement on what list you ought to use either. STD13 is your best bet. The last time the WG "came back from sleep", we were supposed to take on the protocol-profile work. But we just didn't do the work. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 2 06:45:45 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25921F849D; Mon, 2 Apr 2012 06:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333374345; bh=p3bsPMH1reNUynzGGVLFJNsUoPLUF7KB/4bdCs3Ioro=; h=References:In-Reply-To:Mime-Version:Message-Id:From:Date:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=xVvcYSPpZx0FNU+tkuVfsXOvqJY5a4BQV6PbT61rIWmVh3bqwNzDD04BigWZrrkdy omswerU4enmkpc1OvWTuRxpRLBpygDe/nVamkv8mEI6NOSD3jCZwjTRvkq87kIwZBW A9h4tY/gW2YEApeg6K7XirZHn/TaV5xFCTBt4cfQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D5021F849D for ; Mon, 2 Apr 2012 06:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZEuzEZ6D0B6 for ; Mon, 2 Apr 2012 06:45:43 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8B21F849C for ; Mon, 2 Apr 2012 06:45:36 -0700 (PDT) Received: by qafi31 with SMTP id i31so2126786qaf.15 for ; Mon, 02 Apr 2012 06:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=D2AJQrhwoYUT153hz4Do1JbezX7UdO9Vk0pCONTz8TI=; b=HatrIkPjVXY/HGKXqc2GrKGB5muLuBb1NAJKLOfuwX5lKzNqq0fG12ya0zF3TYUkSq uYHyNcAYf+KycWC9IOfK4TiesPU2yPf7s698ivJx1DnEokBWqTAm9lqWrDBDotUOH5uN TtWAuy4rr7ZZFIXkbyHdg+L4vqKel4XHA+yegtejKI+U5aWaJUp60LJ3J0UuFhwQpQ53 0Ts+GqiXsyUOMnH5VC/bCaRbL5SWeRASABwWAczCzuycnVyAiryyJVypnadcjHOx2I9d E473TAdm/jXahuriK3nixO1GDIcEjxw490djPWO3yn01Bj8PQ++2CUdP9Wtqw4i2jKdY Q46w== Received: by 10.229.77.131 with SMTP id g3mr3259981qck.147.1333374336256; Mon, 02 Apr 2012 06:45:36 -0700 (PDT) Received: from [10.1.195.159] (mobile-198-228-192-126.mycingular.net. [198.228.192.126]) by mx.google.com with ESMTPS id w9sm34689749qao.0.2012.04.02.06.45.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Apr 2012 06:45:34 -0700 (PDT) References: <20120326142607.26742.59731.idtracker@ietfa.amsl.com> <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Message-Id: <466E866A-DC61-4368-8437-02473389122B@gmail.com> X-Mailer: iPhone Mail (9B179) From: Scott Rose Date: Mon, 2 Apr 2012 09:45:28 -0400 To: Dick Franks Cc: Paul Hoffman , DNSEXT Working Group Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4062666090723169204==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============4062666090723169204== Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-749949E7-2714-4197-B809-1E071FFEFA63 --Apple-Mail-749949E7-2714-4197-B809-1E071FFEFA63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think it's clunky too and may not be accurate. Some algorithm may be "obso= lete" for DNSSEC but not for other uses. I will tweak it in the revision.=20= Sent via a series of tubes. On Apr 2, 2012, at 9:37 AM, Dick Franks wrote: >=20 > On 2 April 2012 02:11, Paul Hoffman wrote: > "obsolescing" makes me gag hard enough to call it a problem, not a nit. >=20 >=20 > Ugly; but apparently not obsolete, according to my English (EN-GB) dictio= nary! >=20 > obsolesce verb (obsolesced, obsolescing) > intr to become obsolete; to be going out of use. 19c. >=20 > Chambers 21st Century Dictionary --Apple-Mail-749949E7-2714-4197-B809-1E071FFEFA63 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I think it's clunky too and may not be accurate. Some algorithm may be "obsolete" for DNSSEC but not for other uses. I will tweak it in the revision. 

Sent via a series of tubes.

On Apr 2, 2012, at 9:37 AM, Dick Franks <rwfranks@acm.org> wrote:


On 2 April 2012 02:11, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
"obsolescing" makes me gag hard enough to call it a problem, not a nit.


Ugly;  but apparently not obsolete, according to my English (EN-GB) dictionary!

    obsolesce   verb  (obsolesced, obsolescing)
    intr  to become obsolete; to be going out of use. 19c.

    Chambers 21st Century Dictionary
--Apple-Mail-749949E7-2714-4197-B809-1E071FFEFA63-- --===============4062666090723169204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============4062666090723169204==-- From dnsext-bounces@ietf.org Mon Apr 2 07:23:30 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCC121F850B; Mon, 2 Apr 2012 07:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333376610; bh=g/pceFs4yR1+Wm3PQPYewquDgoLrfZrQgii8I2ail68=; h=Date:From:To:Message-ID:In-Reply-To:References:MIME-Version:Cc: Subject:Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Content-Transfer-Encoding:Content-Type: Sender; b=yAP8tnDYvwrna1cK7+v5P59tVrevlhIz3i5hOrgL3pQGsk4dAjnCAKaTMPjDn2p7T D5X8IeVoFVti9QyJNwu8iXKzQBBQ+po0Mlpr7zFNPve01cS7X5DddAyS34HnfP/dNx vJy3jCvASfFxxzQWjQOMumLuO9839SZxwTw3TEY0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B98021F8552 for ; Mon, 2 Apr 2012 07:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EADuqCzIEkuE for ; Mon, 2 Apr 2012 07:23:27 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by ietfa.amsl.com (Postfix) with ESMTP id 8968A21F851D for ; Mon, 2 Apr 2012 07:23:27 -0700 (PDT) Received: by mail.avalus.com (Postfix) with ESMTPSA id E3AFAC5610E; Mon, 2 Apr 2012 15:23:24 +0100 (BST) Date: Mon, 02 Apr 2012 15:23:24 +0100 From: Alex Bligh To: Dick Franks , Paul Hoffman Message-ID: <61757DF72395A302C4DDDFE0@Ximines.local> In-Reply-To: References: <20120326142607.26742.59731.idtracker@ietfa.amsl.com> <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: DNSEXT Working Group Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org CgotLU9uIDIgQXByaWwgMjAxMiAxNDozNzo0MiArMDEwMCBEaWNrIEZyYW5rcyA8cndmcmFua3NA YWNtLm9yZz4gd3JvdGU6Cgo+PiAib2Jzb2xlc2NpbmciIG1ha2VzIG1lIGdhZyBoYXJkIGVub3Vn aCB0byBjYWxsIGl0IGEgcHJvYmxlbSwgbm90IGEgbml0Lgo+Cj4KPiBVZ2x5O8KgIGJ1dCBhcHBh cmVudGx5IG5vdCBvYnNvbGV0ZSwgYWNjb3JkaW5nIHRvIG15IEVuZ2xpc2ggKEVOLUdCKQo+IGRp Y3Rpb25hcnkhCj4KPiDCoMKgwqAgb2Jzb2xlc2NlIMKgIHZlcmLCoCAob2Jzb2xlc2NlZCwgb2Jz b2xlc2NpbmcpCj4gwqAgwqAgaW50csKgIHRvIGJlY29tZSBvYnNvbGV0ZTsgdG8gYmUgZ29pbmcg b3V0IG9mIHVzZS4gMTljLgo+Cj4gwqDCoMKgIENoYW1iZXJzIDIxc3QgQ2VudHVyeSBEaWN0aW9u YXJ5CgpJdCBpcyBhbiBpbnRyYW5zaXRpdmUgdmVyYiAoc2VlICdpbnRyJykgYWJvdmUuICBZb3Ug Y2Fubm90IG9ic29sZXNjZQpzb21ldGhpbmcuIFlvdSBjYW4sIGhvd2V2ZXIsIG1ha2Ugc29tZXRo aW5nIG9ic2VsZXRlLgoKICAgIEFkZGluZyBhIG5ld2x5IHNwZWNpZmllZCBhbGdvcml0aG0gdG8g dGhlIHJlZ2lzdHJ5IHdpdGggYQotICAgaW1wbGVtZW50YXRpb24gc3RhdHVzIG90aGVyIHRoYW4g T1BUSU9OQUwgU0hBTEwgZW50YWlsIG9ic29sZXNjaW5nCi0gICB0aGlzIGRvY3VtZW50IGFuZCBy ZXBsYWNpbmcgdGhlIHRhYmxlIGluIFNlY3Rpb24gMi4yICh3aXRoIHRoZSBuZXcKKyAgIGltcGxl bWVudGF0aW9uIHN0YXR1cyBvdGhlciB0aGFuIE9QVElPTkFMIFNIQUxMIGVudGFpbCBtYWtpbmcK KyAgIHRoaXMgZG9jdW1lbnQgb2Jzb2xldGUgYW5kIHJlcGxhY2luZyB0aGUgdGFibGUgaW4gU2Vj dGlvbiAyLjIgKHdpdGggdGhlCiAgICBuZXcgYWxnb3JpdGhtIGVudHJ5KS4gIEFsdGVyaW5nIHRo ZSBzdGF0dXMgY29sdW1uIHZhbHVlIG9mIGFueSBleGlzdGluZwotICAgYWxnb3JpdGhtIGluIHRo ZSByZWdpc3RyeSBTSEFMTCBlbnRhaWwgb2Jzb2xlc2NpbmcgdGhpcyBkb2N1bWVudCBhbmQKLSAg IHJlcGxhY2luZyB0aGUgdGFibGUgaW4gU2VjdGlvbiAyLjIgYWJvdmUuCisgICBhbGdvcml0aG0g aW4gdGhlIHJlZ2lzdHJ5IFNIQUxMIGVudGFpbCBtYWtpbmcgdGhpcyBkb2N1bWVudCBvYnNvbGV0 ZSBhbmQKKyAgIHJlcGxhY2luZyB0aGUgdGFibGUgaW4gU2VjdGlvbiAyLjIgYWJvdmUuCgpBcHBh cmVudGx5IHlvdSBjYW4gIm9ic29sZXRlIiBzb21ldGhpbmcgKGFzIHVzZWQgdW5kZXIgJ1N0YXR1 cyBvZiB0aGlzCm1lbW8nKSwgc28gJ29ic29sZXRpbmcnIHdvdWxkIGJlIGFuIGFsdGVybmF0aXZl LCBidXQgaXMgYWxtb3N0IGFzIGhvcnJpYmxlCklNSE8uCgotLSAKQWxleCBCbGlnaApfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkbnNleHQgbWFpbGluZyBs aXN0CmRuc2V4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Ruc2V4dAo= From dnsext-bounces@ietf.org Mon Apr 2 07:46:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135D721F84FC; Mon, 2 Apr 2012 07:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333378012; bh=PhIrLjx7MC7xYypkjMpuSKAGlN/4u/FFqx93a8t+Ess=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=u7G7tTZhodg6Hsvvu7W2b4EspvIStETJ2bfAiH9WVVea5Rr0nkBsprsPZlREhHqDH mTxhY9bK23nXun/0Onm2wCj1DWwnZD+jyRPAhLBQvC5gvoKKyLcurCggPHedq7m0MM SILW8n79wB3E6vgEeprK2cjwnNJkn7BvcuPVq0DI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A322B21F84FC for ; Mon, 2 Apr 2012 07:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJjIsDTdkXYC for ; Mon, 2 Apr 2012 07:46:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2D021F84EF for ; Mon, 2 Apr 2012 07:46:50 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q32EkkxZ064163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 07:46:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120402134134.GA22464@mail.yitter.info> Date: Mon, 2 Apr 2012 07:46:46 -0700 Message-Id: References: <20120402134134.GA22464@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] How to reference "DNS"? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Apr 2, 2012, at 6:41 AM, Andrew Sullivan wrote: > On Mon, Apr 02, 2012 at 05:26:04AM -0700, Paul Hoffman wrote: >> Greetings again. A reviewer of the latest TLSA protocol document in the DANE WG has asked us to add a normative reference to the DNS RFCs because implementers would need to understand some of the DNS before using TLSA. That seems fair. However, saying "go read these two antique RFCs that have been updated over a dozen times" doesn't seem all that useful. Is there a better RFC that can be pointed to for "you need to understand some DNS basics"? >> > > No, and there is no agreement on what list you ought to use either. > STD13 is your best bet. Works for me. > The last time the WG "came back from sleep", > we were supposed to take on the protocol-profile work. But we just > didn't do the work. Noted. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 2 09:24:00 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B6C21F8690; Mon, 2 Apr 2012 09:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333383840; bh=IbvIUJAW6p8wKfsL9LgqOLkkFQAq33A+TECaZSpVzfo=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=W/sUcmtLY8UZedQpF+ijkaWDlm2TTA/Vz/TFalEWOi7W1yB7nN5tm/z1Y6M9C0N1V P/QvLubgDKCUSDEpGPETAw8Q/exQxSB/sOomwP3QSqP7QPOgdpX8XjgBxnAorsawzD QM+HXhpa7KQwvmCC+gtGybf4ColfxE0gobBWxpfE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5C221F8690 for ; Mon, 2 Apr 2012 09:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZSHG-6jFR+v for ; Mon, 2 Apr 2012 09:23:58 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id D89D321F8680 for ; Mon, 2 Apr 2012 09:23:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43961) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SEk2u-0002xS-Wm (Exim 4.72) (return-path ); Mon, 02 Apr 2012 17:23:56 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SEk2u-0008EJ-3j (Exim 4.67) (return-path ); Mon, 02 Apr 2012 17:23:56 +0100 Date: Mon, 2 Apr 2012 17:23:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Hoffman In-Reply-To: <1E10703D-4769-4089-ABE7-C23813E30D43@vpnc.org> Message-ID: References: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com> <1E10703D-4769-4089-ABE7-C23813E30D43@vpnc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Cc: DNSEXT Working Group Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-01 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Paul Hoffman wrote: > On Mar 26, 2012, at 3:29 PM, RJ Atkinson wrote: > > > I support the idea of moving ECDSA to "Recommended". > > +1 Sounds good to me, but are there any implementations yet? Tony. -- f.anthony.n.finch http://dotat.at/ Portland, Plymouth: North 3 or 4, backing northwest 5 or 6 later. Slight or moderate. Showers later. Moderate or good. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 2 20:11:00 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B478121F8773; Mon, 2 Apr 2012 20:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333422660; bh=WfLhNG0cXy7uCbbTWmrd0/0pUnfPZvPX0nTjRurg9TA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=niDJbl+wdwQZthSQgNbsZlYC1HfmJVEZMvUMtG7EpzvGKoSFRh6X3bU9g4axFjkqP kwcITlnIufmoxzcKpRQ+YV9GY0Uf+LZfYPoam13FIYRLq6rvOOwlEY9uiVqFtkERmV H/pnLJJcZxP081yIZUXIDlONwHiTUVnIRBc4EIfI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90B121F8773 for ; Mon, 2 Apr 2012 20:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkyT01Hh+59C for ; Mon, 2 Apr 2012 20:10:59 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27EA221F8772 for ; Mon, 2 Apr 2012 20:10:58 -0700 (PDT) Received: by mail-lpp01m010-f44.google.com with SMTP id j5so4642318lag.31 for ; Mon, 02 Apr 2012 20:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=ij30M1giVERlf8uBa8tCt0WqCUuVYT4XwpjLLU6MZqk=; b=TCTixDBXavjsf07Uo2N1O77VsbWUYhPc72pLZbmxXwIu8gw69xgylW2FHCMaTBSWAd Pug2YfAOyHvSJVUU3cOWuDAdPimZM65ZiOAYTNJIbSJVkydED+6MnExE09Qpvz7PMj2D Y8Mf6C1rmzFBNBAazJb1o4xK/cu6tHiLbvPSW2Z0vwtd9ie7IMcYkX5VKoQG0cbhVdhB xOWBWHAqtuQDH6h8cCvlr3MygSbtW8mhcFRIgrCbOgZkp+rLIHVQt0ic6mlF/Ow2EuYv oGUllhUNln258Q8yD9+oRmfUk8TZZ5nLqJ3AG6mNeTPhktaMAW7z7/xsA+9W7NOJNFaa 5eIA== Received: by 10.152.111.198 with SMTP id ik6mr4322797lab.38.1333422658780; Mon, 02 Apr 2012 20:10:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Mon, 2 Apr 2012 20:10:38 -0700 (PDT) In-Reply-To: References: <20120327084731.30282.35216.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 2 Apr 2012 23:10:38 -0400 Message-ID: To: IETF DNSEXT WG Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-rfc6195bis-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I'll change the draft the way the working group wants and I don't plan to post much here. But, to repeat some of what I said at the Paris meeting for the benefit of those not there: I don't think there is any reason everyone needs see every application or any reason for a three week minimum for the Expert to respond. While posting the application by the applicant or expert should be encouraged, as the current draft does, having a relatively quick response is more important IF people want to eliminate the widespread impression that RRTYPE allocation is a lengthy, difficult process. If the timeline and process remain fairly close the current timeline and process, people should expect that prospective applicants will continue to use TXT and/or grab a random RRTYPE number outside the process and use it. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Tue, Mar 27, 2012 at 8:12 PM, Samuel Weiler wrote: > As I said at the microphone in Paris, I would strongly prefer to see > typecode templates posted publicly in all cases. =A0I see no need to shor= ten > the review period beyond the current three weeks. > > Furthermore, as I pointed out on this list on 7 October, IANA seems to not > be maintaining the archive of templates as requested in both RFC5395 and > RFC6195. =A0If we're are going to keep using this template system to allo= cate > typecodes, we need that archive. =A0Absent a commitment from IANA to main= tain > that archive, preferably backed up with evidence that they have populated > that archive with the old templates, I would prefer to see us back out the > RFC5395 changes to the typecode allocation process and revert to the RFC2= 929 > rules. > > -- Sam > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Apr 3 04:12:40 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9137621F86F3; Tue, 3 Apr 2012 04:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333451560; bh=mmFFPDlvqbBhFKUdp100JTC/dQXsDxpykhhwfYZzb28=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=mEt9KOolDEwCgnHJieyzBrsOaZCOeAIJlLcnoo2e79arG/guZ8ztVyjuF7eghkecU E6nfcIk+7ccaIvdYYVImJH2bhjzBljm2LjCs4LVaCHGC8Qh2o0vORl/E/XfJT6xYaH UdnLqomaWO87ni7pdlzZTIiCER5Eb1NWEkNCA4TE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037CA21F8697; Tue, 3 Apr 2012 04:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEMMSLpp2-Jx; Tue, 3 Apr 2012 04:12:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45D721F86F0; Tue, 3 Apr 2012 04:12:37 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120403111237.28679.32208.idtracker@ietfa.amsl.com> Date: Tue, 03 Apr 2012 04:12:37 -0700 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'DNAME Redirection in the DNS' to Proposed Standard (draft-ietf-dnsext-rfc2672bis-dname-25.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org The IESG has approved the following document: - 'DNAME Redirection in the DNS' (draft-ietf-dnsext-rfc2672bis-dname-25.txt) as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2672bis-dname/ Technical Summary The DNS DNAME RRTYPE redirects subtrees of the domain name space. This memo updates the original specification found in RFC 2672. It also aligns RFC 3363 and RFC 4294 with the revision. Working Group Summary The DNS Extensions Working Group has spent a considerable amount of time on this document. It is the product of extended review. The chairs believe the WG consensus to be strong. Document Quality The document is partly the result of experience with the original DNAME specification, and highlights a number of issues that have proven troublesome in practice. In the opinion of the WG, the draft clarifies these issues without introducing wire changes to the protocol. Personnel Andrew Sullivan is the Document Shepherd. Ralph Droms is the responsible Area Director. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Apr 3 07:38:36 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E511E80AD; Tue, 3 Apr 2012 07:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333463916; bh=pPcVlbWIdbK8Thy1xayWtew7ZF7peR766bwnTOUIjIk=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Ye2TMhxpCHUsgs3EyaGfD8+T+eSGGGFYzN4SnpFeT1cV0AzWDAaDJ25QllRsZuBtO z5tYCdIE/T7h4lbJQL5cPwzc+ObOd/e6enNjYAThHBMiQvFd/DvjzqLkNDXCWGUsfm +YWErpPf0q949xWV3IgIyBuN14WYBB8b3WaIsgfw= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C26C11E80AD for ; Tue, 3 Apr 2012 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA49x3g0bTQj for ; Tue, 3 Apr 2012 07:38:34 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 6767C11E80A6 for ; Tue, 3 Apr 2012 07:38:34 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 64D9DE04A4; Tue, 3 Apr 2012 11:38:33 -0300 (BRT) Date: Tue, 3 Apr 2012 11:38:33 -0300 From: Frederico A C Neves To: dnsext@ietf.org Message-ID: <20120403143833.GL15938@registro.br> References: <20120313035508.GA77638@registro.br> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20120313035508.GA77638@registro.br> Cc: iana-prot-param@iana.org Subject: Re: [dnsext] TLSA RRTYPE review - result [IANA #550878] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Dear Colleagues, This message ends the review process for the TLSA RRTYPE. According to my judgment this request meets RFC6195 at both requirements of section 3.1.1 and none of section 3.1.2 and should be accepted. Best Regards, Frederico Neves On Tue, Mar 13, 2012 at 12:55:08AM -0300, Frederico A C Neves wrote: > Dear Colleagues, > > Bellow is a completed template requesting a new RRTYPE assignment > under the procedures of RFC6195. > > This message starts a 3 weeks period for an expert-review of the DNS > RRTYPE parameter allocation for TLSA specified in > http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt > IANA #550878 > > If you have comments regarding this request please post them here > before Apr 3rd 18:00 UTC. > > Best Regards, > Frederico Neves > > --begin 6195 template TLSA-- > A. Submission Date: 12 March 2012 > > B. Submission Type: > [X] New RRTYPE > [ ] Modification to existing RRTYPE > > C. Contact Information for submitter (will be publicly posted): > Name: Warren Kumari > Email Address: warren@kumari.net > International telephone number: +1-571-748-4373 > Other contact handles: > > D. Motivation for the new RRTYPE application. > Encrypted communication on the Internet often uses Transport Level > Security (TLS), which depends on third parties to certify the keys > used. The allocation of this RRTYPE will improve this situation by > enabling the administrator of a domain name to certify the keys used > in that domain's TLS servers by publishing information in the DNS. > > E. Description of the proposed RR type. > A description of the RRtype is in > draft-ietf-dane-protocol-18.txt, Section 2 The TLSA Resource Record > ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt ) > > F. What existing RRTYPE or RRTYPEs come closest to filling that need > and why are they unsatisfactory? > The CERT (37) RR, RFC 4398 is closest. It is not suitable for this > particular use as it is not flexible enough. It *would* be possible > to shoehorn this into the CERT RR, but would be very kludgy. > > G. What mnemonic is requested for the new RRTYPE (optional)? > TLSA > > H. Does the requested RRTYPE make use of any existing IANA registry > or require the creation of a new IANA sub-registry in DNS > Parameters? If so, please indicate which registry is to be used > or created. If a new sub-registry is needed, specify the > allocation policy for it and its initial contents. Also include > what the modification procedures will be. > > This is in the the draft > (http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt). > > It is included here for completeness, but reviewers are encouraged to > consult the draft as the formatting is cleaner. > > #1: TLSA Usages. > A new registry, "Certificate Usages for TLSA Resource Records". > The registry policy is "RFC Required". > The initial entries in the registry are: > Value Short description Reference > ---------------------------------------------------------- > 0 CA constraint [This] > 1 Service certificate constraint [This] > 2 Trust anchor assertion [This] > 3 Domain-issued certificate [This] > 4-254 Unassigned > 255 Private use > > #2: TLSA Selectors > A new registry, "Selectors for TLSA Resource Records". > The registry policy is "Specification Required". > The initial entries in the registry are: > Value Short description Reference > ---------------------------------------------------------- > 0 Full Certificate [This] > 1 SubjectPublicKeyInfo [This] > 2-254 Unassigned > 255 Private use > > #3: TLSA Matching Types > A new registry, "Matching Types for TLSA Resource Records". > The registry policy is "Specification Required". > The initial entries in the registry are: > Value Short description Reference > -------------------------------------------------------- > 0 No hash used [This] > 1 SHA-256 RFC 6234 > 2 SHA-512 RFC 6234 > 3-254 Unassigned > 255 Private use > > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being processed as an > unknown RRTYPE (see [RFC3597])? No. > > J. Comments: > A number of participants in DNSEXT / DNSOPS (and the DNS Directorate) > have been involved in / following / are aware of this work. > --end 6195 template TLSA-- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 4 00:49:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7000621F8681; Wed, 4 Apr 2012 00:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333525744; bh=qog+ly4JkbyoY3JYxBtg0u2riqdc/NRLjHIQv1EIwkQ=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lhjK6tULJYPwDaeEpslWN9u+beWT1xJIsYI6Y8NaJlacgxWjm+7yfh7FLELwlvYb0 8X1vj5cfFNA96fT4Da4wQ4QEArIfq+z1SCRHIua/JXoRm6/3Qvg8PF8pDN/groky7u U2ykiber9uBDoqqJmrp2rvUdMrH+i5sljoSs/aJc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA59D21F8709 for ; Wed, 4 Apr 2012 00:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c0InJxdIfrO for ; Wed, 4 Apr 2012 00:49:02 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E86921F85E4 for ; Wed, 4 Apr 2012 00:49:02 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q347mxgA063747 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 4 Apr 2012 09:49:00 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1333525741; bh=OAbhTbWuNfloPNL1yHNT1DxqaVaiucfHVJwRTQtpuV4=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gKaCGvODC77K5NSWx5ymnByuhNbxFbDelNQi6gRiJ56y1cgczK+0dmW5mCyC5TB4+ CFLUI8cTg+ZKSGzr9Z6bY02D6yeXWGNIpkNYVDNB6Ky37tPyb7VjH3yszF7/DZDF+5 dBGj5UEnJQmzl2Dd9WETD8WtH6IxxY0swSgUtgRE= Message-ID: <4F7BFCEB.4020605@nlnetlabs.nl> Date: Wed, 04 Apr 2012 09:48:59 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: dnsext@ietf.org References: <4DE8BF39-7E68-4F10-BFBE-F4D408628929@gmail.com> <1E10703D-4769-4089-ABE7-C23813E30D43@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.1.2 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 04 Apr 2012 09:49:00 +0200 (CEST) Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-algo-imp-status-01 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/2012 06:23 PM, Tony Finch wrote: > Paul Hoffman wrote: > >> On Mar 26, 2012, at 3:29 PM, RJ Atkinson wrote: >> >>> I support the idea of moving ECDSA to "Recommended". >> >> +1 > > Sounds good to me, but are there any implementations yet? > > Tony. It is implemented in ldns, you have to configure it with --enable-ecdsa. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPe/zrAAoJEA8yVCPsQCW5l7AH/1E2YcDKnI84Bfma7mhTBNZF liRjYUygXGjDsZgif53ddZkVKsR3YjB/kuw1Y3zKILmLnGMrKiYs/1unF7cDWbmo oTTwghsqIkFcNh8Fpw+j/yVdRW6trmOisTVg0OabtgKngIxCxXGC+OgFMJzlrGL9 1f6TI0nBqMcB2XEVPwRMKa469ggPgps4AUTthfoP1Gcamc1eoVm5+dTmR3kUEdo6 Z1tbWPsfBBngoRM8wL5tzLbVtsi3pi5PtPTUPktllGTy5Q2AvyT3ZIEuTS5Dz4PA k7Ft46pbbT1FnUkPmYvR9hTl7CoUSQsd3XRPup/r2hUi5+/qksXriLWC3NoxowA= =pQni -----END PGP SIGNATURE----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 4 08:32:08 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC721F85A4; Wed, 4 Apr 2012 08:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333553528; bh=XHpPT0qjzlzgdsTF15A/5ldb1WAqXPZ2bS3HlFHDjPw=; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=D7KUx4Sz/DussT/8fTmLEy/n8iVuTk18NPaQuSNgwJND8v9Wb9asjh+ch8bwxyefL Y42MilpbYcfMNZtuYJzfRdjgX3reCGaNiNC5AZOKglWfikhfPivc+3IoNmEscrwoaf MRj/SacudrN7Gd4dUQEl6Lzd03bQERnYUwNn3GFI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD94C21F85A4 for ; Wed, 4 Apr 2012 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.649 X-Spam-Level: X-Spam-Status: No, score=-104.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6kGPT9Gv9DA for ; Wed, 4 Apr 2012 08:32:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 70D7C21F85A2 for ; Wed, 4 Apr 2012 08:32:04 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q34FVaNF002966; Wed, 4 Apr 2012 11:32:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.222.11] by Work-Laptop-2.local (PGP Universal service); Wed, 04 Apr 2012 10:32:01 -0500 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 04 Apr 2012 10:32:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 4 Apr 2012 10:31:30 -0500 To: From: Edward Lewis X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Want this to be a WG doc? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org So far I have comments from three people added to the next version-to-be. Frankly, there isn't a lot to this document and it's based on observations. I don't see it as being all that interesting or in need of much "work" despite the fact that inputs to date have improved the document. The answer I seek now is whether this comes in as a -00 in WG name or goes to a -02 version under a personal submission. (I.e., window dressing.) All in all, the WG has shown a low amount of energy for this (rightly so) but when I tried independent submission I was told this is a matter for the WG to look at. The old "catch-22" (see http://en.wikipedia.org/wiki/Catch_22). The IANA editor has informally expressed support for this as a way to clean up dangling references in the DNS parameters page. This is the reason the document has resurfaced. So, WG or not? Individual or not? I just want to get this moving and done. At 11:17 +0200 3/29/12, Edward Lewis wrote: >Any thoughts on whether the following would be a DNSEXT document? >I'm asking DNSOP too. > >http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 4 09:02:34 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D56821F87E1; Wed, 4 Apr 2012 09:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333555354; bh=C4vQVwxSIr3kJBQE7avzJ4/KaZgqrSxp+2OTmZyehx8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Ngl4kPSnOEXgYjBb6c51CiAba0qeSQ1d2hvYzA2nj2QJWeC7ZDMG7ftS3YOypcVTQ MZBeuJv+w/aTNYdz45YWWJcsqJ4/6MSvrSUaXUhsa8QA0oD0S+pURa2OLP3oCyXk4+ BbMid+pb2W0ezQGgDjmXqbyf26bt81HeCDG+Imm8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247A121F87E1 for ; Wed, 4 Apr 2012 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lamd3Fw6Y5Dl for ; Wed, 4 Apr 2012 09:02:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 207FF21F848E for ; Wed, 4 Apr 2012 09:02:31 -0700 (PDT) Received: by lagj5 with SMTP id j5so607926lag.31 for ; Wed, 04 Apr 2012 09:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=tXDWQSnlsS7PcDsyIoKUxqC+lXA7S1mi9x4rFfYtFw8=; b=cH/gbyvaZ7OPmJki76T3M7uXRsCeNzDToF4auhrr5PNUqXtYEtP1Q3/OLAf0E9hjc6 lgZjfmoZRH0RlcAlrzrMKZNZSo1I4DWtL46pZdJbDaqB7mG3FFB/cXdH4nxeBl52rp2x uG8l+GzL6XdUxp8NqTnAWWlHdy6OMbdH0aiVc/CLA1e/+mXRmyC2gwCD/mVwNMg1Bpri rET/7cBvgbjSMf5EJtX4KyitU6X+wJWPT9DjKxiKaQmoYz10i98reKarzJYOcC6VNCYi XkzRgzg+8kEKgSYjiilSp86M0yynmcBGkH2xJm8NmSHgzeEsa4+cTB+fq3TiPKbRlPdJ sUxw== Received: by 10.152.131.66 with SMTP id ok2mr19432994lab.10.1333555350945; Wed, 04 Apr 2012 09:02:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Wed, 4 Apr 2012 09:02:10 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 4 Apr 2012 12:02:10 -0400 Message-ID: To: Edward Lewis Cc: dnsext@ietf.org Subject: Re: [dnsext] Want this to be a WG doc? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I support making this a working group document and will review it. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Wed, Apr 4, 2012 at 11:31 AM, Edward Lewis wrote: > So far I have comments from three people added to the next version-to-be. > > Frankly, there isn't a lot to this document and it's based on observation= s. > =A0I don't see it as being all that interesting or in need of much "work" > despite the fact that inputs to date have improved the document. > > The answer I seek now is whether this comes in as a -00 in WG name or goes > to a -02 version under a personal submission. =A0(I.e., window dressing.) > > All in all, the WG has shown a low amount of energy for this (rightly so) > but when I tried independent submission I was told this is a matter for t= he > WG to look at. =A0The old "catch-22" (see > http://en.wikipedia.org/wiki/Catch_22). > > The IANA editor has informally expressed support for this as a way to cle= an > up dangling references in the DNS parameters page. =A0This is the reason = the > document has resurfaced. > > So, WG or not? =A0Individual or not? =A0I just want to get this moving an= d done. > > > At 11:17 +0200 3/29/12, Edward Lewis wrote: >> >> Any thoughts on whether the following would be a DNSEXT document? I'm >> asking DNSOP too. >> >> http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01 > > > -- > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > Edward Lewis > NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice mess= age at +1-571-434-5468 > > 2012...time to reuse those 1984 calendars! > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 4 17:01:06 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2653211E811C; Wed, 4 Apr 2012 17:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333584066; bh=nEjxt/8n+sGbi5/mQqBpLBpgcapCnZmqbR1y3dk4BIU=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ccXiBHDKLbgWxFo84Fm7VoA2c+icTYcO+h9wTB9sLltS8wtBvr2V/EhhLO8q/C8yp eg+232seVKKBhFsZclrrXFxjdAsxN7Awihvjerm4TfZp3SCzycaHZVjyfXpy08XNt3 L4/aUrUOzVSIwINn1DluLkDmaNt4DOjE18Hutfgo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D982E11E811C for ; Wed, 4 Apr 2012 17:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.874 X-Spam-Level: X-Spam-Status: No, score=-96.874 tagged_above=-999 required=5 tests=[AWL=1.875, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rgF4eK0Fdvd for ; Wed, 4 Apr 2012 17:01:03 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 33AE611E80FE for ; Wed, 4 Apr 2012 17:01:01 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA019963990; Thu, 5 Apr 2012 01:59:50 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA00145; Thu, 5 Apr 2012 01:59:48 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204042359.BAA00145@TR-Sys.de> To: Ed.Lewis@neustar.biz Date: Thu, 5 Apr 2012 01:59:48 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-lewis-dns-undocumented-types-01 -- was: Want this to be a WG doc? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Pleeeeze use concise, 'speaking' Subject lines that allow to identify the document you talk about! So this is about draft-lewis-dns-undocumented-types-01. I support the document and already have reviewed it, but did not send comments so far because I only had noted minor editorial nits, and I thought the I-D was intended as a 'lingering' informational draft for the information of the WG (cf. Datatracker WG state "For WG Info only") and the interested DNS community -- which I expect to roughly follow dnsext anyway. :-) However, the I-D IMHO would make a good Individual (AD-sponsored) submission, since the directions to IANA will be bound to rfc6195bis. The document "simply" assembles the results of archive research and does not need formal WG adoption and support or IETF consensus. So, this way, the WG overhead incurred with formal draft adoption would be avoided, and if the idea of the document is properly described to the AD, it should not take too much time to bring it forward as an Informational RFC. Given the current circumstances, it might be better for the WG to not adopt additional work that is not closely related to protocol specification, but to help support it on the alternate path to RFC publication. As an alternative, we might consider including the body of the draft as an Informative Appendix into the rfc6195bis draft; this way, IANA would find the necessary material to retrofit the missed past actions for the RRtype registry during the publication process for rfc6195bis. However, if the AD refuses the individual submisison or the WG does not like this 'combining' of I-Ds, but the WG indicates its general support of the I-D, it could also be submitted as an Independent Submission to the RFC-ISE; then the IESG only has to confirm lack of collision with work in DNSEXT and elsewhere in the IETF. BTW: Unfortunately, there is a big grain of salt with publishing this I-D as an RFC: Much of the substance of the draft is based on precise URLs to semi-official documents, which RFC Editor policy will likely to allow to be included 'as is'. If these documents will eventually be available as escrow copies at the IANA site, linked to the registry entries, the need for the subject draft will melt down, although the updated references to these copies would likely make it better suitable for RFC publication. :-( Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 5 00:41:32 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5905C21F86FC; Thu, 5 Apr 2012 00:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333611692; bh=eJOjnuI3GPKstKR6R0BNxDekS80ws2XwPyBGkYXnCTo=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=PkDFIeCkwLX0lwD6QIyKfyeRexvwvk2PL7loIcmN76yjNoblLDpiT2hwZOETpu+Fy 8i7sd0LbwRHmmywk8MYoS1IhY5uY9NOSpqIMJSNgxh4b6tXJ5Ortb8xeagd+KrejR6 ljTr5z7XtC4Mw3EEDDm1Q6nvce58ue925WXR4uM0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F2121F86FA for ; Thu, 5 Apr 2012 00:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q+zLu6jlWRs for ; Thu, 5 Apr 2012 00:41:30 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D364321F86F9 for ; Thu, 5 Apr 2012 00:41:29 -0700 (PDT) Received: from [192.168.178.27] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q357fObV071446 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 5 Apr 2012 09:41:25 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1333611689; bh=H5CJLjhgvbXXcDRd3ls1+n9y3l5LSZ9EbGiMO9VHpOw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=yxuO/u4hR0VJ+MdbVHj+RjqVtOkfkBAQWQ9PR9W1D5tF4qN0GRtKuvb1UYgwn6bu9 a25Eyg4VIVhDeUyxewKLshrqVzJLW2m1+PBiNSTJxJS1kYmQ1spjf+WG1dbIiO8RM9 R9Vzcm9181zZTHU2pFLhn7XykP1mFtcWU5AYKcU8= Message-ID: <4F7D4CA4.1000401@nlnetlabs.nl> Date: Thu, 05 Apr 2012 09:41:24 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: dnsext@ietf.org References: <201203091900.UAA00760@TR-Sys.de> In-Reply-To: <201203091900.UAA00760@TR-Sys.de> X-Enigmail-Version: 1.1.2 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Thu, 05 Apr 2012 09:41:25 +0200 (CEST) Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 -- questions on s3.2.3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQpIYXNoOiBTSEExCgpIaSwKCk9uIDAz LzA5LzIwMTIgMDg6MDAgUE0sIEFsZnJlZCDvv70gd3JvdGU6Cj4gRm9sa3MgLS0gaW4gcGFydGlj dWxhciBpbXBsZW1lbnRlcnMsCj4gCj4gQSBwb2ludCBoYXMgYmVlbiByYWlzZWQsIGFuZCBmb3Ig cXVhbGlmaWVkIGFjdGlvbiwgdGhlIGRyYWZ0IGF1dGhvcnMKPiBuZWVkIG1vcmUgaW5mb3JtYXRp b24gYW5kIG9waW5pb25zIG9uIHRoaXMgcGFydCBvZiB0aGUgZHJhZnQ6Cj4gCj4gfDMuMi4gIElY RlIgUmVzcG9uc2UKPiB8Cj4gfFsuLi5dCj4gfAo+IHwzLjIuMy4gIEFuc3dlciBTZWN0aW9uCj4g fAo+IHwgIFRoZSBBbnN3ZXIgc2VjdGlvbiBNVVNUIGJlIHBvcHVsYXRlZCB3aXRoIHRoZSB6b25l IGNoYW5nZSBpbmZvcm1hdGlvbgo+IHwgIG9yLCBpbiB0aGUgY2FzZSBvZiBmYWxsYmFjayB0byBB WEZSLCB0aGUgZnVsbCB6b25lIGNvbnRlbnRzLgo+IHwKPiB8ICBGb3IgbXVsdGktbWVzc2FnZSBJ WEZSIHJlc3BvbnNlcywgdGhlIGNvbmNlcHRpb25hbCBhbnN3ZXIgaXMgc3BsaXQKPiB8ICBpbnRv IHNlZ21lbnRzIHRoYXQgYXJlIHNlbnQgaW4gb3JkZXIuICBFYWNoIHNlZ21lbnQgaXMgY29tcHJp c2VkIG9mCj4gfD4gYW4gaW50ZWdlciBudW1iZXIgb2YgZnVsbCBSUnMsIGFuZCBmb3IgdHJhbnNw b3J0IGVmZmljaWVuY3ksIHRoZQo+IHw+IHJlc3BvbnNlIG1lc3NhZ2VzIHNob3VsZCBiZSBmaWxs ZWQgdXAgd2l0aCBhbnN3ZXIgUlJzIGFzIG11Y2ggYXMKPiAgICAgICAgICAgICAgICAgICAgICBe Xl5eXl4KPiB8PiBwb3NzaWJsZSBmb3IgdGhlIHJlc3BvbnNlIG1lc3NhZ2Ugc2l6ZSBjaG9zZW4g YnkgdGhlIElYRlIgc2VydmVyLAo+IHw+IHRha2luZyBpbnRvIGFjY291bnQgdGhlIHNwYWNlIG5l ZWRlZCBmb3IgdGhlIG90aGVyIHNlY3Rpb25zIGluIHRoZQo+IHw+IG1lc3NhZ2VzLgo+IHwKPiB8 ICAgWy4uLl0KPiAKPiBRdWVzdGlvbnM6Cj4gCj4gYSkgIERvZXMgdGhlIGJlaGF2aW9yIGRlc2Ny aWJlZCBpbiB0aGUgZW1waGFzaXplZCBzZW50ZW5jZSAgbWFrZQo+ICAgICBzZW5zZSwgZ2l2ZW4g dGhlIG9wdGltaXNhdGlvbiBnb2FscyB1bmRlcmx5aW5nIHRoZSBJWEZSIGRlc2lnbiA/CgpJIGNh biBzZWUgd2h5IGZpbGxpbmcgdXAgdGhlIHJlc3BvbnNlIGFzIG11Y2ggYXMgcG9zc2libGUgaXMg bW9yZQplZmZpY2llbnQgd2l0aCByZXNwZWN0IHRvIHRyYW5zcG9ydCAoY2hhbmNlIHRoYXQgbGVz c2VyIHBhY2tldHMgd2lsbCBiZQpuZWVkZWQpLiBUbyBtZSBpdCBtYWtlcyBzZW5zZS4KCj4gYikg IERvIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBmb2xsb3cgdGhpcyBkaXJlY3Rpb24gPwoKV2Ug ZG9uJ3QgaGF2ZSBhbiBJWEZSIHNlcnZlciBpbXBsZW1lbnRhdGlvbiAoeWV0KSwgYnV0IGZvciB3 aGF0IGl0cwp3b3J0aDogTlNEIGhhbmRsZXMgdGhpcyBhcHByb2FjaCBmb3IgQVhGUi4KCk9wZW5E TlNTRUMgd2lsbCBiZSBhYmxlIHRvIHNlcnZlciBzaWduZWQgWEZScyBpbiB2ZXJzaW9uIDEuNCBh bmQgdXAgYW5kCml0IGZvbGxvd3MgdGhpcyBkaXJlY3Rpb24gZm9yIGJvdGggSVhGUiBhbmQgQVhG Ui4KCj4gYykgIFNoYWxsIHdlIHJlcGxhY2UgdGhlIHRhZ2dlZCAic2hvdWxkIiBieSBhICJTSE9V TEQiLAo+ICAgICB0byBtYWtlIHRoZSByZWNvbW1lbmRhdGlvbiBldmVuIHN0cm9uZ2VyID8KCkkg ZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIGFib3V0IHRoaXMsIHNvIEkgYW0gZ3VpZGVkIGJ5 IFJGQzIxMTkgdGhhdApzYXlzIHVzZSB0aGVzZSB0ZXJtcyB3aXRoIGNhcmUgYW5kIHNwYXJpbmds eS4gTXkgZmVlbGluZyBpcyB0aGF0Cmxvd2VyY2FzZSBzaG91bGQgaXMgZmluZSBoZXJlLgoKQmVz dCByZWdhcmRzLAogIE1hdHRoaWpzCgo+IAo+IAo+IEtpbmQgcmVnYXJkcywKPiAgIEFsZnJlZC4K PiAKCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tClZlcnNpb246IEdudVBHIHYxLjQuMTEg KEdOVS9MaW51eCkKQ29tbWVudDogVXNpbmcgR251UEcgd2l0aCBNb3ppbGxhIC0gaHR0cDovL2Vu aWdtYWlsLm1vemRldi5vcmcvCgppUUVjQkFFQkFnQUdCUUpQZlV5a0FBb0pFQTh5VkNQc1FDVzVX dlFJQUt6WVNJWm1tN0FPWEVrMXQ4THd2THVvCnJJdlVQcTZzNVlmaWFUanlpdVIyNDdWYjZoNU1F Y1pJQi9FcnR0SUZ4aTNnRXFJZXRBR2NWOWs4NDBxRkgzRjIKSnZMaXB0bUpsUjl2ZWcwWUtyTDJy bVVMYUoycG1haWkxcVdPK0xmUnN1QTM3U25UZXpkL2g5MVNQM01BeEhGaQpMNGg0YndsdVg2ZEFF RFNTWEZqeVprT0Q5L2tuL1crbldNdkpXcWI4SGI5MFNZUVYxMElranBtSG9RZ1FlWWRICkFML3dV TFEwaGhUZlVjYnl3Nkllc1kxWWxOKzFPaDFoR2pCU3k1YmZNMXdVK1ZpRmcyN3VCT0VETUtRT1Zi cUgKc1FXbFhJTnB3eFA0a0Jwa1BCNFlpbHpWZFkwSndNMWs1WnFrbmtTaENaSmhtd05Bb3Y4ZWR0 NW5vYzQvOG4wPQo9bmZHaAotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZG5zZXh0IG1haWxpbmcgbGlzdApk bnNleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNl eHQK From dnsext-bounces@ietf.org Thu Apr 5 01:58:14 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2902C21F86FA; Thu, 5 Apr 2012 01:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333616294; bh=Af5ztKeg7RMUyUwnS72s2eRkCNSoqeIYh/7WkSi6hkA=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=S+5mEB9oYhYy9lzeaVbs748bgjxDQQhf5YNOrM1jbUsglsHPTcJB0priKIGRiUTkj lHf7QiULEfzUGqv4uRPJqC/xjUprf6l3ewgulVfSXxY0Wll9TdISNjtG13s1y5A1H4 7xsmKNJPPoV6YUVdSWk7p9cfYyVaYdy9ExZIsHjw= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0221F8701 for ; Thu, 5 Apr 2012 01:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.194 X-Spam-Level: * X-Spam-Status: No, score=1.194 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om09ClMm-Twb for ; Thu, 5 Apr 2012 01:58:11 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 1A4C121F86FA for ; Thu, 5 Apr 2012 01:58:10 -0700 (PDT) Received: (qmail 15906 invoked from network); 5 Apr 2012 09:28:11 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 5 Apr 2012 09:28:11 -0000 Message-ID: <4F7D5E50.2070405@necom830.hpcl.titech.ac.jp> Date: Thu, 05 Apr 2012 17:56:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <20120327080711.16297.49879.idtracker@ietfa.amsl.com> In-Reply-To: Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Though appendix A has some abstract statements, I still can't see any realistic operational reason to have IXFR-ONLY. For operational examples discussed in ML, it is merely necessary, in section 6.3, to state optional condensation is "NOT RECOMMENDED". Masataka Ohta _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 5 09:56:44 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80AD21F86E0; Thu, 5 Apr 2012 09:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333645004; bh=/lYW8UIIBrCBfR6OBKZzKOwJu9sYhGVz5aXPUmcz4sU=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=kg09+TQRDq2Ht9K15QLXBUmOR0tIyBqvlvxmBt/9wDgfvXsPx86Ac59iRFVXtJbXd EFqwdc9c9GzA1XVL1efseGeDBXmYXlGtl5pI76MMjlRTnorg9iqeg7PtWH6fuh1c+N ZZHgFCoptTbSlR/WfSgBRgvi+q5eAcM9GwVTW4xU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FC121F86F5 for ; Thu, 5 Apr 2012 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wr8jLy2kAaD for ; Thu, 5 Apr 2012 09:56:43 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 572E121F86D8 for ; Thu, 5 Apr 2012 09:56:43 -0700 (PDT) Received: from [192.168.2.168] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 7F97F1705C; Thu, 5 Apr 2012 16:56:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) From: David Conrad In-Reply-To: Date: Thu, 5 Apr 2012 09:56:40 -0700 Message-Id: <5E66E55E-8E3C-4668-B3C5-4E55BBAA9BCE@virtualized.org> References: To: Edward Lewis X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] Want this to be a WG doc? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Apr 4, 2012, at 8:31 AM, Edward Lewis wrote: > So, WG or not? WG. > Individual or not? Err. Not? > I just want to get this moving and done. Good work and I'll review. Regards, -drc _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 6 08:09:44 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3E321F8541; Fri, 6 Apr 2012 08:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333724984; bh=13yL277hXTe9zAWSoJC4c6ifNHRvWdytGm1T13Ek6vs=; h=Message-Id:From:To:Date:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:MIME-Version: Content-Type:Content-Transfer-Encoding:Sender; b=Qpnff6uaDRdEe6gL5atMrQuan3poE1pb68ncWbPanK/DiPKNvNT3Y9SpmHrqVBbqf FgkPcu/zM4ezj8CXOCvq0p3M/iCytBlIqG5TnUsVTL37zo8rZ6Q/v5n9x1gXO+mfwN pgTOQ/o0Xq0uxOPxcTz3Gs6tp9kzRxVwciMA35p8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8EE21F8541 for ; Fri, 6 Apr 2012 08:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVcEgf4U3hZL for ; Fri, 6 Apr 2012 08:09:43 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 0479321F84CE for ; Fri, 6 Apr 2012 08:09:42 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q36F9g1l017556 for ; Fri, 6 Apr 2012 17:09:42 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204061509.q36F9g1l017556@givry.fdupont.fr> From: Francis Dupont To: dnsext@ietf.org Date: Fri, 06 Apr 2012 17:09:42 +0200 Subject: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I am refreshing the ECDSA experimental support in bind9 so I have some random comments: - my Fedora 16 compiles OpenSSL with no Elliptic Curve support (and of course no ECDSA). If someone wants to put some pressure to get this fixed, I'll join! - in http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml SHA-384 is OPTIONAL. I believed the idea was to use it with the new ECDSA keys, so this will have to be fixed in the long term. BTW how? - I still have a question about the 256/384 pair: are they supposed to be handled as two different algos (as RSASHA1 and RSASHA256, or RSASHA256 and RSASHA512) or as the same algo with two different "strengths"? Note at the beginning (i.e., when I asked this many months ago) it was only a concern for the signer but according to a recent discussion it is concern for resolvers too. - I have the performance figures with the last OpenSSL (1.0.1) and its new assembly support (aka enable-ec_nistp_64_gcc_128), unfortunately not available for P384 (can't see why)? ECDSA is really faster on signing and the verifying is still reasonable, so Paul's prediction about EC support quality was correct. Regards Francis.Dupont@fdupont.fr PS: I am not the right person to ask for ECDSA support in the next distribs (I don't say you shouldn't ask). PPS: it should be good to get the examples with a date in the future. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 6 08:21:13 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8870221F8570; Fri, 6 Apr 2012 08:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333725673; bh=8L360aSNCRaKATfkCIwF4HDAf/br8ocvFdM7PIvUKck=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=DDd1Cpk6+bQ1woC5vGiVsYOlNFpPqB/ZV3I2M38uaCdl184OYaakIUhbdVuwnlKoV Og9VTNDPOmJaGvXRFgGgqTg77A+U3ZBDlOJEusjVEWtA8V8li2oahK6t6LZNbqOkgX W097+sPMItEOtN6FpcJAwtZTAno99CzEl+9y0kMI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE821F857F for ; Fri, 6 Apr 2012 08:21:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoKgmiIc3QxL for ; Fri, 6 Apr 2012 08:21:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BB79A21F8570 for ; Fri, 6 Apr 2012 08:21:06 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q36FKuEn044698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Apr 2012 08:20:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201204061509.q36F9g1l017556@givry.fdupont.fr> Date: Fri, 6 Apr 2012 08:20:57 -0700 Message-Id: References: <201204061509.q36F9g1l017556@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Apr 6, 2012, at 8:09 AM, Francis Dupont wrote: > - my Fedora 16 compiles OpenSSL with no Elliptic Curve support (and > of course no ECDSA). If someone wants to put some pressure to get > this fixed, I'll join! This is a compile-time option for OpenSSL. If the version of OpenSSL that comes with Fedora 16 doesn't have the option, you can download a fresh version of OpenSSL and build it locally. > - in http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml > SHA-384 is OPTIONAL. I believed the idea was to use it with the new > ECDSA keys, so this will have to be fixed in the long term. BTW how? Recycling of political discussion; deferred. > - I still have a question about the 256/384 pair: are they > supposed to be handled as two different algos (as RSASHA1 and > RSASHA256, or RSASHA256 and RSASHA512) or as the same algo > with two different "strengths"? Note at the beginning (i.e., > when I asked this many months ago) it was only a concern for > the signer but according to a recent discussion it is concern > for resolvers too. They are different algorithms with different strengths, so your either/or question doesn't make sense. Similarly, each of the defined SHA-2 variants are also different algorithms and each has a different strength. > - I have the performance figures with the last OpenSSL (1.0.1) > and its new assembly support (aka enable-ec_nistp_64_gcc_128), > unfortunately not available for P384 (can't see why)? > ECDSA is really faster on signing and the verifying is still > reasonable, so Paul's prediction about EC support quality > was correct. Good to hear. > PS: I am not the right person to ask for ECDSA support in > the next distribs (I don't say you shouldn't ask). Diddling with OpenSSL in the various Linux distros may not be such a good idea... > PPS: it should be good to get the examples with a date in > the future. Too late. :-) --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 6 11:23:53 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7E21F8601; Fri, 6 Apr 2012 11:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1333736633; bh=RdP3k3O7dupvCaUdvxCo4XfZELtZIuMJTJupFKxJ5do=; h=Message-Id:From:To:In-reply-to:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=fVJPNVMAy5h4qhQjEiF9eBaKkyfOzbUgKYY8DRQQiuKuWXgIUYAHV6dFiGJc8VwhP EA4ZwUoncqyTNT1vltbRbpRjaQvipD3/yzKXIz0OrGplmQWZS+SJmqsKiycQDSL3JE y72XDcLUqxi6Fyu15XVyg7lFJX8VLAUS7Maj8doQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C1B21F85E7 for ; Fri, 6 Apr 2012 11:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWPFDxolRZW4 for ; Fri, 6 Apr 2012 11:23:51 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E950521F8499 for ; Fri, 6 Apr 2012 11:23:50 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q36INnkS029691; Fri, 6 Apr 2012 20:23:49 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204061823.q36INnkS029691@givry.fdupont.fr> From: Francis Dupont To: Paul Hoffman In-reply-to: Your message of Fri, 06 Apr 2012 08:20:57 PDT. Date: Fri, 06 Apr 2012 20:23:49 +0200 Cc: dnsext@ietf.org Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In your previous mail you wrote: > > - my Fedora 16 compiles OpenSSL with no Elliptic Curve support (and > > of course no ECDSA). If someone wants to put some pressure to get > > this fixed, I'll join! > > This is a compile-time option for OpenSSL. => in fact a configure-time option: after this unexpected (:-) test of the ECDSA support detection, I looked at the .spec file: OpenSSL was configured with 'no-ec no-ecdh no-ecdsa'... > If the version of OpenSSL that comes with Fedora 16 doesn't have the > option, you can download a fresh version of OpenSSL and build it > locally. => I did this and took the opportunity to try the new 1.0.1 version. > > - I still have a question about the 256/384 pair: are they > > supposed to be handled as two different algos (as RSASHA1 and > > RSASHA256, or RSASHA256 and RSASHA512) or as the same algo > > with two different "strengths"? Note at the beginning (i.e., > > when I asked this many months ago) it was only a concern for > > the signer but according to a recent discussion it is concern > > for resolvers too. > > They are different algorithms with different strengths, so your > either/or question doesn't make sense. Similarly, each of the defined > SHA-2 variants are also different algorithms and each has a different > strength. => I'll rephrase the question: does it make sense to use ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for the KSK? > > PS: I am not the right person to ask for ECDSA support in > > the next distribs (I don't say you shouldn't ask). => oops, I should have added "bind9" here. Thanks Francis.Dupont@fdupont.fr _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Apr 10 06:50:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36D711E80B6; Tue, 10 Apr 2012 06:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334065815; bh=ADNvmbQypYUf4ayUZHMTnh36s6BenaeN/OhUH1DgSd0=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ONh2xxus8rMWyFBZe2sW5IL203XQWnkr653hGVt1A1MbhJ5h6KlGZPpvzdrPJUo67 uO0sWMQXhn6WeBFntFhN5rlqJoXTK34s1NA/Qjk6wmqPMgBJe3QXfU+mXNETQvU0Xn aBRtk8GpS4pg/ykVULJAKy3skVs4TiSeJgudwHNY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D055C11E80AF for ; Tue, 10 Apr 2012 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5plXoUz-4MZf for ; Tue, 10 Apr 2012 06:50:12 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C7A11E80AB for ; Tue, 10 Apr 2012 06:50:12 -0700 (PDT) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3ADo9da078785 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 10 Apr 2012 15:50:10 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334065811; bh=QyTX2+PYKTxt0OONMyKlXmSRlnwXyRC4VnEUG8HVMQA=; h=Date:From:To:Subject:References:In-Reply-To; b=MSBMMW+ZdrCi02NMwqdYMCeWDkR5hTPJJKjjXztfuPwUxL5AyQw2P/VERcglL5vpK DjFPXyDVuphl6OumdFDGJspBiTga3MF0KWJis39iuc9zoNc2azBvS2bjz0k3BXAo4P CRx62O0Wd6OXByQGOeieKSnZWFhcL9m78mWbZdNo= Message-ID: <4F843A91.4020808@nlnetlabs.nl> Date: Tue, 10 Apr 2012 15:50:09 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <201204061823.q36INnkS029691@givry.fdupont.fr> In-Reply-To: <201204061823.q36INnkS029691@givry.fdupont.fr> X-Enigmail-Version: 1.4 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 10 Apr 2012 15:50:10 +0200 (CEST) Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Francis, On 04/06/2012 08:23 PM, Francis Dupont wrote: >>> - I still have a question about the 256/384 pair: are they >>> supposed to be handled as two different algos (as RSASHA1 and >>> RSASHA256, or RSASHA256 and RSASHA512) or as the same algo with >>> two different "strengths"? Note at the beginning (i.e., when I >>> asked this many months ago) it was only a concern for the >>> signer but according to a recent discussion it is concern for >>> resolvers too. The first not the latter, like RSASHA1 and RSASHA256, they are different algorithms. Use the same algorithm for your ZSK and KSK (but apply different policy). >> They are different algorithms with different strengths, so your >> either/or question doesn't make sense. Similarly, each of the >> defined SHA-2 variants are also different algorithms and each has >> a different strength. > > => I'll rephrase the question: does it make sense to use > ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for the KSK? No, that is dnssec-bogus. The ECDSAP384SHA384 for KSK but does not sign the zone is a signing-error. You must sign the entire zone with that algorithm, if you use it. The algorithm-support is signalled per-algorithm in DS and DNSKEY records, not for a range or suite of algorithms. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPhDqRAAoJEJ9vHC1+BF+N4oQP/2j9F82vwsPHqygq2Tsye1ba I25E0S6AdFsn2jqg1iQNm6Z1H/kG8XQvND+2nv4CzOeWwIOKpEpsw0jDSh3BwbCC im5ggmfFqMsHE8tQ3e18xXTbPV4WtiXgwLJEo5omQElURfZZRf4f8H1yLW5SPvA9 C/baKkfnAmY7u7UIMHQh/x2xp57WIgYq/RW6NHbbh1C8oylnf061flBAGgxa2NLu sHtYMiEEQuqGKiGklthh5TlqoGOqI41zbRWQlSaStSpjK/OofkfDXJR5mwzQB9BS NTUNgVojVi0TgQqHv8bn1WwEqiiPaiJc/3CkXDu2maqwWu3AMd+K45Cw89v7kSeZ BcEHEiv991+/lWcTGhYWSIuZNzV73zPLhAgZC/8lHiEJlwdfvSTvTnm3d7LUyNm6 AJJM/1ze1IdkBb81bCxP+2SBecjajqV69C9fdG23uMPazcQElbkpARRrFrhqTCCK wrjVA9ygDeStgHX1h/HTt3NuCi99UwPP2Wm+qw85+6Dtv9C4tCwC01KvqaxGmnjm h+oxEInVJvYhg+WRet1jH/x1hppRusvRF/B5PZHX1Tkk9Jzcte8MpqVcx1TSN4na rhTEoVMKs+ylmxKISHDl+doPqGZEF0kgmoLFGLxu1XtnVMU1GqJX0GTqTIKquDeo q0EKcTRCZRdTcpOxYZoz =7av+ -----END PGP SIGNATURE----- _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Apr 10 08:25:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA6911E80EA; Tue, 10 Apr 2012 08:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334071504; bh=xiU2SzevbXNd1R7JZxXuzWPwNs+wekL3QpfgJwy5MBs=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=MwfWjodXWBujNhwtq+jCH2rpxhHDWJHXIYWNKhH+iaCFZ3l+UeNRwUlwSr1fAw3rK N2aHxFVe9wXaEQ6kxgo4J4K0VCGAFtFgbMVj04CxgtG9QGFj6eO9FKcCDGC8UlqVSq aVpfQEJbz5Uzrt6o4ycxaFXV4mRH72L1RGu1glQg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046FC11E80DF for ; Tue, 10 Apr 2012 08:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRjuPJB-sy4g for ; Tue, 10 Apr 2012 08:25:02 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC4011E80CD for ; Tue, 10 Apr 2012 08:25:02 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id E73486A7; Tue, 10 Apr 2012 08:25:01 -0700 (PDT) From: Wes Hardaker To: Francis Dupont References: <201204061823.q36INnkS029691@givry.fdupont.fr> Date: Tue, 10 Apr 2012 08:25:01 -0700 In-Reply-To: <201204061823.q36INnkS029691@givry.fdupont.fr> (Francis Dupont's message of "Fri, 06 Apr 2012 20:23:49 +0200") Message-ID: <0l7gxnvcc2.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org >>>>> On Fri, 06 Apr 2012 20:23:49 +0200, Francis Dupont said: >> This is a compile-time option for OpenSSL. FD> => in fact a configure-time option: after this unexpected (:-) test of FD> the ECDSA support detection, I looked at the .spec file: OpenSSL was FD> configured with 'no-ec no-ecdh no-ecdsa'... It's worse than that: they've also removed the code from their compile. So even if you pull the spec and rebuild with their package, you still need to use an original (unmodified) upstream source tar-ball. But the good news is that it's still pretty easy. -- Wes Hardaker SPARTA, Inc. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 11 03:57:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4762011E8086; Wed, 11 Apr 2012 03:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334141835; bh=BZeKuENHy1JSo2a9OP7jakPSTAcpywbDteTdKXnxxHg=; h=Message-Id:From:To:In-reply-to:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=lJGq5b+V9wV3BbNjtQTwD4wvGte81E0imqM0p9ffA50IfWL4jWK1r/aOHftRW2Dik bxM6pKe+jqc4dqZr2SQ/QsddRii7dbcBF72J4c1gQF2zM0xgkpsETRZ8GqgK1VOaiM Q+tXShMoEJ2M+J7lupRvGSInE2Y4TN3/II540sYg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7D211E8086 for ; Wed, 11 Apr 2012 03:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf5z7Q9QEX4X for ; Wed, 11 Apr 2012 03:57:14 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 9A09B11E8075 for ; Wed, 11 Apr 2012 03:57:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3BAvCSF044106; Wed, 11 Apr 2012 12:57:12 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204111057.q3BAvCSF044106@givry.fdupont.fr> From: Francis Dupont To: "W.C.A. Wijngaards" In-reply-to: Your message of Tue, 10 Apr 2012 15:50:09 +0200. <4F843A91.4020808@nlnetlabs.nl> Date: Wed, 11 Apr 2012 12:57:12 +0200 Cc: dnsext@ietf.org Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In your previous mail you wrote: > On 04/06/2012 08:23 PM, Francis Dupont wrote: > >>> - I still have a question about the 256/384 pair: are they > >>> supposed to be handled as two different algos (as RSASHA1 and > >>> RSASHA256, or RSASHA256 and RSASHA512) or as the same algo with > >>> two different "strengths"? Note at the beginning (i.e., when I > >>> asked this many months ago) it was only a concern for the > >>> signer but according to a recent discussion it is concern for > >>> resolvers too. > > The first not the latter, like RSASHA1 and RSASHA256, they are > different algorithms. Use the same algorithm for your ZSK and KSK > (but apply different policy). => note my question is really about the application of the word "same" to ECDSAP256SHA256 / ECDSAP384SHA384 (a priori if they have different code points and names they are not the "same", now RSA has a degree of freedom which is not present in ECDSA). > >> They are different algorithms with different strengths, so your > >> either/or question doesn't make sense. Similarly, each of the > >> defined SHA-2 variants are also different algorithms and each has > >> a different strength. > > > > => I'll rephrase the question: does it make sense to use > > ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for the KSK? > > No, that is dnssec-bogus. The ECDSAP384SHA384 for KSK but does not > sign the zone is a signing-error. You must sign the entire zone with > that algorithm, if you use it. The algorithm-support is signalled > per-algorithm in DS and DNSKEY records, not for a range or suite of > algorithms. => I agree but I want to be sure it is the intented thing. If there is no opposed opinion in the list I follow you. Thanks Francis.Dupont@fdupont.fr _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 11 04:45:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E68421F8666; Wed, 11 Apr 2012 04:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334144712; bh=5WsRC7oQG/6Fs1VD5dF7vUIiJf+2tF+YBXkoAK0tyws=; h=Message-Id:From:To:In-reply-to:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=RQ716ilrBxRmkH5G3vayiTzZphVUmCIJmzlRH9sXOLjhUDcxStFrrVaUtW7goGp77 eSR8edGdeQxR2i3TUGwccL40kQAtIyMRA9+28YSwgsgxXbyqu2Ym1ZrHtKo03K3qFo h8yzMYY5gyK1ycnPzqeCmh0J27+gJDSOxj4OLiGg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C4A21F8666 for ; Wed, 11 Apr 2012 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUHXOAxRgKPs for ; Wed, 11 Apr 2012 04:45:10 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 3394521F8665 for ; Wed, 11 Apr 2012 04:45:10 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3BBj5TF047091; Wed, 11 Apr 2012 13:45:06 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204111145.q3BBj5TF047091@givry.fdupont.fr> From: Francis Dupont To: Wes Hardaker In-reply-to: Your message of Tue, 10 Apr 2012 08:25:01 PDT. <0l7gxnvcc2.fsf@wjh.hardakers.net> Date: Wed, 11 Apr 2012 13:45:05 +0200 Cc: Paul Hoffman , dnsext@ietf.org Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In your previous mail you wrote: > FD> => in fact a configure-time option: after this unexpected (:-) test of > FD> the ECDSA support detection, I looked at the .spec file: OpenSSL was > FD> configured with 'no-ec no-ecdh no-ecdsa'... > > It's worse than that: they've also removed the code from their compile. > So even if you pull the spec and rebuild with their package, you still > need to use an original (unmodified) upstream source tar-ball. > > But the good news is that it's still pretty easy. => as far as I can understand from the Fedora mailing-lists, the reason is patents on EC technology... Regards Francis.Dupont@fdupont.fr _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 11 09:15:48 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66F21F855F; Wed, 11 Apr 2012 09:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334160948; bh=UmLBktzYSEgwhMYWYG/I+gSl0noAyDYaXS63ukB3mDs=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=UTDw5LmB9zwklARnLX8OWl/FVwbW73XsDmKYo33cmga15j7MTMnWrs3w4Ler4rxUP +bwBYeKm+mupssAyKSepUoVMW5NmXYcnrRIPNoZjjaXFF6fqo1Dy5387YnAPswX2Yv mNApPkMDHxTcM0k7zhf+qtfmlTfq0X9Wv1IsUkJ8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A4611E8089 for ; Wed, 11 Apr 2012 09:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2itgz+4-KQf for ; Wed, 11 Apr 2012 09:15:46 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89311E8085 for ; Wed, 11 Apr 2012 09:15:46 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 866D9469; Wed, 11 Apr 2012 09:15:44 -0700 (PDT) From: Wes Hardaker To: Francis Dupont References: <201204111145.q3BBj5TF047091@givry.fdupont.fr> Date: Wed, 11 Apr 2012 09:15:44 -0700 In-Reply-To: <201204111145.q3BBj5TF047091@givry.fdupont.fr> (Francis Dupont's message of "Wed, 11 Apr 2012 13:45:05 +0200") Message-ID: <0l1unu6y8f.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Cc: dnsext@ietf.org, Paul Hoffman Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org >>>>> On Wed, 11 Apr 2012 13:45:05 +0200, Francis Dupont said: FD> => as far as I can understand from the Fedora mailing-lists, the reason FD> is patents on EC technology... Yep. They do it to a number of packages. [ref: mp3 decoding] -- Wes Hardaker SPARTA, Inc. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 11 09:22:40 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEAA21F8581; Wed, 11 Apr 2012 09:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334161360; bh=M9scFeSF6tj5F3H4HXvbApFVLK1heXFSvabOEJRk8Pc=; h=References:In-Reply-To:Mime-Version:Message-Id:From:Date:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=IPCwMlIBVTGYz3wHSx8E1L7I450OLq8rhdqVPWd398vzQ5Pju7As/71pPjxUixXB5 tE0sGsOQz5bd66yylZF2uUHzmdLXGtVZBvOOTmtqhUUf318i3hY4t3qadyIzAwg4dE F/eXdHo9Fxhm2HZK1qekTMNvzYfc7UVUVy9GnTEA= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756E821F8581 for ; Wed, 11 Apr 2012 09:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GR9Y08Fzkb3 for ; Wed, 11 Apr 2012 09:22:37 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9695821F855F for ; Wed, 11 Apr 2012 09:22:35 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id wfFX1i0061c6gX85CgNcoC; Wed, 11 Apr 2012 16:22:36 +0000 Received: from [192.168.6.70] ([64.134.236.139]) by omta23.westchester.pa.mail.comcast.net with comcast id wgMy1i01B318Cko3jgN5wu; Wed, 11 Apr 2012 16:22:31 +0000 References: <201204111145.q3BBj5TF047091@givry.fdupont.fr> In-Reply-To: <201204111145.q3BBj5TF047091@givry.fdupont.fr> Mime-Version: 1.0 (1.0) Message-Id: <0A1BDBB3-243B-4B57-806A-B707A9EAAE04@comcast.net> X-Mailer: iPad Mail (9B176) From: Michael StJohns Date: Wed, 11 Apr 2012 12:22:00 -0400 To: Francis Dupont Cc: "dnsext@ietf.org" , Paul Hoffman Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org To be specific, it's not because of the patents, but because of the fear the patents might apply to the code, a fear not shared by OpenSSL for the original code, by BouncyCastle for its java and C# providers, and Oracle for the EC code in JDK 1.7. Oh yeah, for NSS from Mozilla. Mike Sent from my iPad On Apr 11, 2012, at 7:45, Francis Dupont wrote: > In your previous mail you wrote: > >> FD> => in fact a configure-time option: after this unexpected (:-) test of >> FD> the ECDSA support detection, I looked at the .spec file: OpenSSL was >> FD> configured with 'no-ec no-ecdh no-ecdsa'... >> >> It's worse than that: they've also removed the code from their compile. >> So even if you pull the spec and rebuild with their package, you still >> need to use an original (unmodified) upstream source tar-ball. >> >> But the good news is that it's still pretty easy. > > => as far as I can understand from the Fedora mailing-lists, the reason > is patents on EC technology... > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 11 20:03:19 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0970811E8083; Wed, 11 Apr 2012 20:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334199799; bh=dKwj/LBKP3CbdaxSa0NV+LJjWKCyXrPSY8Y0H4j8ijw=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=svb8xlpMmJCHaU1TLN921hn3GOG4wIzqRpKHwmFwJ2pXJ7s+pMSPhtuSjJBj/yTnO q/yf66hapTqRdqOCGHHGgIRJrSgAGWjevlHsmOCZlCcgoNkk4JGcfkuWHT6u4/K6Sf 3MKO1+5wamN5LCF5Uz89mhUAp56K65LC5bUvshZE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC12511E8083 for ; Wed, 11 Apr 2012 20:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcwgyFPHclQE for ; Wed, 11 Apr 2012 20:03:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32F11E8075 for ; Wed, 11 Apr 2012 20:03:17 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3C33GOv053241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 11 Apr 2012 20:03:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Date: Wed, 11 Apr 2012 20:03:16 -0700 Message-Id: <6246A80E-20CB-4AEE-AB1C-AF86E840C03B@vpnc.org> To: DNSEXT Working Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dnsext] IETF LC for DANE X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org The TLSA protocol from the DANE WG has just entered IETF Last Call: Plenty of DNS-aware folks have been active in the discussion of the document, but more input is always welcome. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 12 00:14:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8267D21F84EB; Thu, 12 Apr 2012 00:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334214866; bh=vqYCC+bYASIYgLXbE1a7Dl9IJjRj6cAx2AagVkHnoS8=; h=Date:From:To:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=heZC5cUhuvunqLdn6GjGS9dUUVkNvdtIZZI9o8kO2TWrwKbSgcehLwiQ82gIB24bQ OzwQ0BD365R48T6oc9I7UUCU2aNcwKiDVpjqfR9QcUWJDEiBaoPAS5/uVL8IFfepDa 61rXz0RyGpoPvcl/U7fWpCoQILYSdzv+JvODSR6U= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96D21F84EB for ; Thu, 12 Apr 2012 00:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHiH0iIxxfAU for ; Thu, 12 Apr 2012 00:14:24 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2621F84B4 for ; Thu, 12 Apr 2012 00:14:23 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 313093FF5D; Thu, 12 Apr 2012 09:14:21 +0200 (CEST) Date: Thu, 12 Apr 2012 09:14:21 +0200 From: Miek Gieben To: dnsext WG Message-ID: <20120412071421.GA19834@miek.nl> Mail-Followup-To: dnsext WG MIME-Version: 1.0 User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: [dnsext] draft-hoffman-dnssec-ecdsa-04 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4500193160266770607==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============4500193160266770607== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I've (re)read and implemented dnssec-ecdsa-04 in some code. During that process I got some questions about it: * Section 1: It says ECDSA is 20 times faster than RSA for signing and 5 times slower for validating. Shouldn't that require a reference? * Section 4: How should I know that, x and y are of equal length? * Section 4: Same question for r and s? * Section 6: In the examples the privatekey file is shown. I haven't seen (or can't remember) this in any previous RFC specifing new algorithms for DNSKEYs. Also all other (DSA/RSA) .priv key files (as generated by = BIND)=20 put the public key info in the .priv file, this one is an exception. Wh= y? (My local elliptic curve documentation tells me the the private key con= sists out of the public key and a bigInt called D) Kind regards, --=20 Miek Gieben --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+GgMwACgkQJYuFzziA0Pa3rgCgjpfokJQ6Wb5xylyqQdlVaCj4 OhAAoMjsCf5GFfS/JRHH7c1LOYic+ANX =3KzJ -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- --===============4500193160266770607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============4500193160266770607==-- From dnsext-bounces@ietf.org Thu Apr 12 04:17:22 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D668021F8593; Thu, 12 Apr 2012 04:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334229441; bh=91ZwxyNaiwEdPZMEzX4Pz050AeDt6QooxNEUxGVXdEg=; h=Message-Id:From:To:In-reply-to:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=ZNiQwXVu09E/rQfTv8jBps3lsUtWb5YYJm1EwlaZqBbSIarCs7yYh3A5HjjwO+L9G YyPzrP7tbCuYMCS7GO7a1Y8y8EXjFR+uyF4aYKDNf4V1E5Ne9IPjUltjYHM8RFBLmW MmH3+09a+FrLYXDfEOBjyyoLwMmdwr3OngzEiSOo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1502421F8533 for ; Thu, 12 Apr 2012 04:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSsGikce81rS for ; Thu, 12 Apr 2012 04:17:20 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 3593721F84DA for ; Thu, 12 Apr 2012 04:17:20 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3CBHIi5033363; Thu, 12 Apr 2012 13:17:18 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204121117.q3CBHIi5033363@givry.fdupont.fr> From: Francis Dupont To: Miek Gieben In-reply-to: Your message of Thu, 12 Apr 2012 09:14:21 +0200. <20120412071421.GA19834@miek.nl> Date: Thu, 12 Apr 2012 13:17:18 +0200 Cc: dnsext WG Subject: Re: [dnsext] draft-hoffman-dnssec-ecdsa-04 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In your previous mail you wrote: > I've (re)read and implemented dnssec-ecdsa-04 in some code. During that > process I got some questions about it: > > * Section 1: It says ECDSA is 20 times faster than RSA for signing > and 5 times slower for validating. Shouldn't that require a reference? => I got the same differences at a lower level. BTW it seems both RSA and ECDSA are very sensible to optimizations, the only thing which seems unlikely is ECDSA signing not very faster than RSA signing, and ECDSA validating faster than RSA. > * Section 4: How should I know that, x and y are of equal length? => as the public key is an opaque bit string I don't believe it matters (and if you need to know the FIPS 186-3 should provide all details). > * Section 4: Same question for r and s? => in fact they can get leading zeros so not the length you expect. IMHO the critical thing is (quoting the I-D): For P-256, each integer MUST be encoded as 32 octets; for P-384, each integer MUST each be encoded as 48 octets. > * Section 6: In the examples the privatekey file is shown. I > haven't seen (or can't remember) this in any previous RFC > specifing new algorithms for DNSKEYs. Also all other (DSA/RSA) > .priv key files (as generated by BIND) put the public key info > in the .priv file, this one is an exception. Why? => RFC 5933 (about GOST for DNSSEC, which is BTW another EC stuff). > (My local elliptic curve documentation tells me the the private > key consists out of the public key and a bigInt called D) => usually the public key is not considered as being a part of the private key. I know some PKCS#11 devices which don't return the public values when a RSA private key is looked up (note IMHO it is a bad behavior). Here it is clear the private key is a bigInt. Thanks Francis.Dupont@fdupont.fr PS: as far as I can see the example is hard to use to test code: the only thing you can do is to validate old/expired signatures... PPS: the crypto answer is Q = dG so the public key Q is trivial to compute from the private key d and the curve parameters (which includes the generator G). _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 12 04:25:15 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE81B21F8598; Thu, 12 Apr 2012 04:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334229915; bh=Lmr1rPJ39F1CAfOUMfWoMIigon2smk9011PjXT5LsM0=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=OZCdyuGwnZhsCdokoYt3PMLLiWDOyEi2gCt+MEGG9oGiWKbs+DrEjVTDLfTtE62EC xi+FKl82GaSBmZl49rqkH9GBU9uaaIA/VYIPTcMQ17Y4iz9ujhgEegmgn1FMzap2mx k3JEtMoxLmPbBnuPF+UPZWdHM6zstylzFkNz0Mm8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAEF21F8598 for ; Thu, 12 Apr 2012 04:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOuCCqzgdB2V for ; Thu, 12 Apr 2012 04:25:14 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 098AA21F8594 for ; Thu, 12 Apr 2012 04:25:14 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id F0D2C4030E; Thu, 12 Apr 2012 13:25:09 +0200 (CEST) Date: Thu, 12 Apr 2012 13:25:09 +0200 From: Miek Gieben To: dnsext WG Message-ID: <20120412112509.GA25406@miek.nl> Mail-Followup-To: dnsext WG References: <20120412071421.GA19834@miek.nl> <201204121117.q3CBHIi5033363@givry.fdupont.fr> MIME-Version: 1.0 In-Reply-To: <201204121117.q3CBHIi5033363@givry.fdupont.fr> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] draft-hoffman-dnssec-ecdsa-04 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3081106284800868462==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============3081106284800868462== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [dnsext] draft-hoffman-dnssec= -e..." ] >=20 > =3D> in fact they can get leading zeros so not the length you expect. > IMHO the critical thing is (quoting the I-D): > For P-256, each integer MUST be encoded as 32 octets; for > P-384, each integer MUST each be encoded as 48 octets. Ah, I completely missed that and now I know way: browser caching :( Thanks. > > * Section 6: In the examples the privatekey file is shown. I > > haven't seen (or can't remember) this in any previous RFC > > specifing new algorithms for DNSKEYs. Also all other (DSA/RSA) > > .priv key files (as generated by BIND) put the public key info > > in the .priv file, this one is an exception. Why? >=20 > =3D> RFC 5933 (about GOST for DNSSEC, which is BTW another EC stuff). Ok, so we are stuck with that. > PS: as far as I can see the example is hard to use to test code: > the only thing you can do is to validate old/expired signatures... > PPS: the crypto answer is Q =3D dG so the public key Q is trivial to > compute from the private key d and the curve parameters (which > includes the generator G). Thanks for you answers. Regards, --=20 Miek Gieben --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+Gu5UACgkQJYuFzziA0PawnACgoKCo+Kdd52dEG4Spjne2egZJ 1F8AoN8zGJjPT96sIYOEDs6X6WuhDhWU =HA1w -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- --===============3081106284800868462== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============3081106284800868462==-- From dnsext-bounces@ietf.org Thu Apr 12 06:17:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BEF21F8606; Thu, 12 Apr 2012 06:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334236672; bh=gCPkWAbbqjTH7FkeWdvstk2fF6sYWubm5BQXoYFRcQg=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=hMVU82zHdmFhc+LT4z9AzDGCPtQcclgbHilVXyUToe/u1lrtaV1lqBnvzOYnTzDQy cD6JOVLTHUgCHH47wv3QIKLDvHr+QoXY/b0f/dohj24WbAunVmi8FiLKszhqXmYrxo sx6VyvNVdFih0IbEJHFYpSljayU1tw7ojjs5U9Ks= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF62B21F8552 for ; Thu, 12 Apr 2012 06:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOF4uMawOTJJ for ; Thu, 12 Apr 2012 06:17:49 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD021F8633 for ; Thu, 12 Apr 2012 06:17:49 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q3CDHlZw074537 for ; Thu, 12 Apr 2012 09:17:47 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F86D5FA.8070800@ogud.com> Date: Thu, 12 Apr 2012 09:17:46 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <201204111057.q3BAvCSF044106@givry.fdupont.fr> In-Reply-To: <201204111057.q3BAvCSF044106@givry.fdupont.fr> X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] about ECDSA X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On 11/04/2012 06:57, Francis Dupont wrote: > In your previous mail you wrote: > >> On 04/06/2012 08:23 PM, Francis Dupont wrote: >> >>> - I still have a question about the 256/384 pair: are they >> >>> supposed to be handled as two different algos (as RSASHA1 and >> >>> RSASHA256, or RSASHA256 and RSASHA512) or as the same algo with >> >>> two different "strengths"? Note at the beginning (i.e., when I >> >>> asked this many months ago) it was only a concern for the >> >>> signer but according to a recent discussion it is concern for >> >>> resolvers too. >> >> The first not the latter, like RSASHA1 and RSASHA256, they are >> different algorithms. Use the same algorithm for your ZSK and KSK >> (but apply different policy). > > => note my question is really about the application of the word > "same" to ECDSAP256SHA256 / ECDSAP384SHA384 (a priori if they > have different code points and names they are not the "same", > now RSA has a degree of freedom which is not present in ECDSA). > >> >> They are different algorithms with different strengths, so your >> >> either/or question doesn't make sense. Similarly, each of the >> >> defined SHA-2 variants are also different algorithms and each has >> >> a different strength. >> > >> > => I'll rephrase the question: does it make sense to use >> > ECDSAP256SHA256 for ZSKs and ECDSAP384SHA384 for the KSK? >> >> No, that is dnssec-bogus. The ECDSAP384SHA384 for KSK but does not >> sign the zone is a signing-error. You must sign the entire zone with >> that algorithm, if you use it. The algorithm-support is signalled >> per-algorithm in DS and DNSKEY records, not for a range or suite of >> algorithms. > > => I agree but I want to be sure it is the intented thing. > If there is no opposed opinion in the list I follow you. > Think of the two ECDSA allocations as two DIFFERENT algorithms, if you elect to use KSK and ZSK split (which I do not think not always needed) ECDSA does not allow you the flexibility to pick strength for the various roles. Thus you pick the ECDSA algorithm that your KSK role needs/demands. Olafur _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 12 06:45:10 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2066121F8593; Thu, 12 Apr 2012 06:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334238310; bh=4y4QxxGohm1lxLX7ifH3+SpALvTsazU7WXC1mkvBJ2E=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=qaTxEImL85deOJg8Lt1tHu2gztnYZ5j2I4BOsI1QhT2v+SWrG54Yu0qM/pZ0hjiMq 3XzhrHOYj0K50hgMcUfF0ENTXJdKWrM29sVqkvGRDkjqW4Pv0cOKyGGhoJnsvT7lPF +tJ6jndQZtEkHM11G9VBAvITdc1Ei3MMB2/sBd9E= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CE921F8593 for ; Thu, 12 Apr 2012 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe9DAbFNcJOz for ; Thu, 12 Apr 2012 06:45:08 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9CB21F853F for ; Thu, 12 Apr 2012 06:45:08 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 619C4402CD; Thu, 12 Apr 2012 15:45:02 +0200 (CEST) Date: Thu, 12 Apr 2012 15:45:02 +0200 From: Miek Gieben To: dnsext WG Message-ID: <20120412134502.GA1173@miek.nl> Mail-Followup-To: dnsext WG References: <20120412071421.GA19834@miek.nl> <201204121117.q3CBHIi5033363@givry.fdupont.fr> MIME-Version: 1.0 In-Reply-To: <201204121117.q3CBHIi5033363@givry.fdupont.fr> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] draft-hoffman-dnssec-ecdsa-04 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1317473394436937277==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============1317473394436937277== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting in "Re: [dnsext] draft-hoffman-dnssec-e..." ] > => in fact they can get leading zeros so not the length you expect. > IMHO the critical thing is (quoting the I-D): > For P-256, each integer MUST be encoded as 32 octets; for > P-384, each integer MUST each be encoded as 48 octets. I'm still an ECC noob (and I expect other people reading this might also lack some crypto skills), but are those integers *always* 32 or 48 octets? I.e there is never a need for padding? Regards, Miek Gieben --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+G3F4ACgkQJYuFzziA0Pb87QCfel/nhKP5UpZ94cTogd8rN7o1 GjYAoNL27FZnUO6RRLWtsN2pec+XHgbN =mGlQ -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- --===============1317473394436937277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============1317473394436937277==-- From dnsext-bounces@ietf.org Thu Apr 12 16:49:20 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57F721F8738; Thu, 12 Apr 2012 16:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334274560; bh=8Cjmxqt49gU+oRb7TZHf6d/5vSlI1jqA69XcxHFTxR4=; h=To:From:Message-Id:Date:Cc:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:MIME-Version: Content-Type:Content-Transfer-Encoding:Sender; b=Xw4EKKxVENuyBG6fsjDED4qzrgo8/oXl2voz03xVPnva0qE9CAdxNoAc1Jy4ew3KW NR6RNW7lisiUVn77PGvfYeB/Ochvvud6NgRcZwIhunT0yBdBGAWIqTcuALCJTFutlT /s6+kZ3aVlEb2amytlxNoR588erhwPDHjq9ch7dQ= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CA521F8734; Thu, 12 Apr 2012 16:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.082 X-Spam-Level: X-Spam-Status: No, score=-104.082 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4CWusadY3Ee; Thu, 12 Apr 2012 16:49:18 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id E708021F872A; Thu, 12 Apr 2012 16:49:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 41A5FB1E003; Thu, 12 Apr 2012 16:48:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120412234838.41A5FB1E003@rfc-editor.org> Date: Thu, 12 Apr 2012 16:48:38 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] RFC 6605 on Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 6605 Title: Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC Author: P. Hoffman, W.C.A. Wijngaard Status: Standards Track Stream: IETF Date: April 2012 Mailbox: paul.hoffman@vpnc.org, wouter@nlnetlabs.nl Pages: 8 Characters: 14332 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-ecdsa-07.txt URL: http://www.rfc-editor.org/rfc/rfc6605.txt This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 13 01:55:24 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FF521F8730; Fri, 13 Apr 2012 01:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334307324; bh=KRbn1oPGyJTMv/PukC7jQubhUoX3KevzRTgQj8ye7ZI=; h=Message-Id:From:To:In-reply-to:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=iAkq8DGOXiFnzWwTgPZDarcu+hfsp4ACS4Df4X7asZgvSanTTcRVOvb1lEShMHZUk JHFyjwBdRj+S4mW0hbynUHoODTIbbySeW6M+1IENm3cFpMWRU+XLKmA+dJVULScCWZ tWDz2XdPFId70sS+UV6BC9RrvyWKCU7XHakEG4dg= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E4F21F871E for ; Fri, 13 Apr 2012 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiiDLQZ3rchW for ; Fri, 13 Apr 2012 01:55:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id A6C1F21F8730 for ; Fri, 13 Apr 2012 01:55:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3D8tCXK012213; Fri, 13 Apr 2012 10:55:12 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204130855.q3D8tCXK012213@givry.fdupont.fr> From: Francis Dupont To: Miek Gieben In-reply-to: Your message of Thu, 12 Apr 2012 15:45:02 +0200. <20120412134502.GA1173@miek.nl> Date: Fri, 13 Apr 2012 10:55:12 +0200 Cc: dnsext WG Subject: Re: [dnsext] draft-hoffman-dnssec-ecdsa-04 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In your previous mail you wrote: > I'm still an ECC noob (and I expect other people reading this might also lack > some crypto skills), but are those integers *always* 32 or 48 octets? I.e there > is never a need for padding? => they can get leading zeros so you can have to pad them to the required size. Regards Francis.Dupont@fdupont.fr _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 13 08:26:05 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6CA21F8647; Fri, 13 Apr 2012 08:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334330765; bh=vRI2TGHxhZ3asLHWK+RAcR3QhYJZ93a+Sx8STHN63rs=; h=From:Message-Id:To:Date:Mime-Version:Content-Type: Content-Transfer-Encoding:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=v4egt+7TINJbhA4+++0zSLqWlEs13ghJiOjQ4X1yXU9eu9hXY4Nih50BlSb/AC9l2 1klFAivE+zSnrNdG2nbhHLrbQSq5owOxO/ch8SQAqnEdtn1bZDH8D7VnGvhxxMbF8w oBmMjNaPWzU//WJ9ZLkpzqd7e7AMdUGES5fBogTs= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7D121F8647 for ; Fri, 13 Apr 2012 08:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.483 X-Spam-Level: X-Spam-Status: No, score=-97.483 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, OBSCURED_EMAIL=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+lvfkWl28kC for ; Fri, 13 Apr 2012 08:26:01 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3697321F863D for ; Fri, 13 Apr 2012 08:25:58 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA071410684; Fri, 13 Apr 2012 17:24:44 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA28225; Fri, 13 Apr 2012 17:24:43 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204131524.RAA28225@TR-Sys.de> To: dnsext@ietf.org Date: Fri, 13 Apr 2012 17:24:43 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM1334330683-28173-0_ Content-Transfer-Encoding: 7bit Subject: [dnsext] RFC 6605 (ECDSA in DNSSEC) -- Q & A X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --ELM1334330683-28173-0_ Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit DNSEXT folks, in particular prospective implementers, I have had some off-list conversations on ECDSA for DNSSEC and have been encouraged to make the material available and somehow linked to the just published RFC 6605. So now I start a new thread that should make it easier to be found when looking for information related to that RFC. I try to send my contribution as a .txt attachment. If desired, the Chairs could include this material into the WG wiki. This is staged like a FAQ -- although strictly speaking, the questions so far have not been asked "frequently". Feel free to follow up with more questions and answers! In the answers, I've tried to simplify very much to make the material understandable for non-specialists; please don't shoot me once you detect I have over-simplified some detail. :-) Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ --ELM1334330683-28173-0_ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=rfc6605-ecdsa-faq.txt Content-Description: initial version of RFC 6605 (ECDSA in DNSSEC) Q&As Content-Transfer-Encoding: 7bit +++++++++++++++++++++++++++++++++++++++++++++++++ Q: Why should ECDSA for DNSSEC be implemented? A: The major benefit that comes with ECDSA (in comparison to RSA signatures) is the much smaller size of keys and signatures for same or better cryptographical strenght. This largely impacts DNS zone sizes and response sizes, and hence network and server load and potential protocol complications. See the Introduction of [RFC6605] for more information. NIST is a driving force for ECC that puts pressure on the market far beyond its proper bailiwick, U.S. government related use. NIST has only approved RSA signatures until 2015 and calls for the support of ECDSA "(or similar)" by September 2015 for all DNS software components to be considered for U.S. federal use. In a recent message to the DNSOP list, I have provided related quotes from [SP800-81] -- see item (A.4) in the message archived at http://www.IETF.ORG/mail-archive/web/dnsop/current/msg09551.html In the excerpts from NIST SP 800-81r1, page 9-4: "[...] The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before Septhember 30th, 2015. ... and from the same document, on page 9-6: "The use of RSA in DNSSEC is approved until the year 2015. By this time, it is expected that Elliptic Curve Cryptigraphy will be specified in the DNSSEC. USG DNSSEC administrations should plan to migrate to the use of ECDSA (or similar) when it becomes available in DNSSEC components." ... one can see that there are strong market forces at work. The commercial pressure to qualify for USG (U.S. Government) use of networking components and software will likely lead to widespread support soon. There's nothing like "(or similar)" in view currently as an alternative. +++++++++++++++++++++++++++++++++++++++++++++++++ Q: Why are there two algorithm numbers, with fixed key size each, assigned for ECDSA use with DNSSEC? A: For digital signatures RSA and DSA, the underlying arithmetics are based on modulo computations relative to very large prime numbers that are chosen at random during private key generation. Therefore, implementations must ba able to handle general mod-p arithmetics and cannot be optimized for special cases. Restrictions on key sizes are imposed by using balanced hash algorithms before signing and the related standards covering these combinations. Therefore, the 'classical' DNSSEC algorithm numbers assigned cover a span of key sizes, and the key size must be specified with the keys. Unlike this, the arithmetics employed on elliptical curves make sophisticated use of all field operations (including division) and therefore can afford using a prime number base of only modest size. The prime is only one of the EC domain parameters to be chosen carefully, and the choice of these is better not left to the key generation procedure. On the other hand, if the parameters are predetermined, one can benefit from code optimization specifically crafted for the prime number characteristic of these fields. The recommended EC domain parameter sets are specifically vetted by the cryptographic community to make sure that known potential attack vectors on the problem to invert the presumed one-way function, exponentiation in a finite group, on which ECC is based (discrete logarithm problem over the respective groups). For instance, for the P-256 EC group, the underlying field has characteristic p = 2^(256)-2^(224)+2^(192)+2^(96)-1 (cf. RFC 5114 or SECG 2); so one can easily see that reduction mod p (needed to implement mod-p multiplication) can be implemented in uint32 arithmetics by using only a few word shift operations and several addition/subtraction operations (basic application of the distributive law). Therefore, efficient implementations of ECC are necessarily specific per EC group. RFC 6605 has standardized a single, commonly favored EC group for each of the two cryptographic "strength" levels 128 and 192, and matched these EC groups with the SHA-2 family hash algorithm of corresponding strength (which is roughly half the width of the hash output, due to the birthday paradoxon). So we have two new DNSSEC algorithms with fixed key (and signature) size in RFC 6605 and in the IANA registry: Algo Number 13 Description ECDSA on Curve P-256 with SHA-256 Mnemonic ECDSAP256SHA256 and Algo Number 14 Description ECDSA on Curve P-384 with SHA-384 Mnemonic ECDSAP384SHA384 Note that the cryptographic community believes that the former corresponds to crypto-strenght 128 and is roughly equivalent to RSA/DSA with 3kbit keys and SHA-256, whereas the latter has crypto-strenght 192, which is roughly equivalent to RSA/DSA with 7.5kbit keys and SHA-384. +++++++++++++++++++++++++++++++++++++++++++++++++ Q: For RSA/DSA, the code has to deal with variable-size numbers and padding. For ECDSA that seems to be different. Are those integers *always* 32 or 48 octets? I.e., there is never a need for padding? A: Yes, and Yes. Where RSA needs computations on really huge numbers, which deserve some careful memory management, the computations needed to perform practicable Elliptic Curve crypto stuff are all modulo a prime number of modest size -- these primes are just below 2^256 or 2^384, respectively, for the two EC groups in current focus, dubbed P-256 and P-384 (definitions of the group parameters including these prime numbers are reproduced e.g. in RFC 5114, Sect. 2.6/2.7). This bit size -- corresponding to 32/48 octets -- is much more managable, so the code can be written to operate on more or less statically defined "super-long" integer variables of a _fixed_ size in the same way as classical uint32 or uint64 data types actually operate modulo 2^32 or 2^64. You traditionally never bother about leading (most significant) zero bits when performing computations with uint32 / uint64 data, and so you don't for the arithmetics over finite fields of modest prime order that represent the coordinate spaces for the Elliptic Curves of interest. For highly optimised code, the best optimisations are quite specific to the underlying finite field of the EC group; that's why efficient implementations of the arithmetics better be per-group, and therefore each EC group is treated as a specific algorithm for DNSSEC purposes. +++++++++++++++++++++++++++++++++++++++++++++++++ Q: Why are private keys and public keys so different in ECC, and why do we need only so much shorter keys and signatures in comparison to RSA and DSA? A: RSA and DSA mostly operate with "simple" (yet very large) integer numbers. With DSA or classical Diffie-Hellman, the private key is the exponent x for the public key y=g^x, with a pre-defined base g, which all are integers (modulo some base). For RSA, things are similar, but a bit more complicated. For ECC, the groups are usually written additively, so what is exponentiation above looks like multiplication with an integer; but the integer multiplication in ECC means repeated addition of the same group element, but group element are points on an Elliptic Curve, which are mostly represented in affine coordinates -- like a point (x,y) in common, planary geometry --; however, here both coordinates are elements of a finite field, not real numbers. For our purposes, the field is of order p, which is a prime number of moderate size. The generator G of the group thus is G = (G_x,G_y), with some mathematical restrictions on the coordinate values (imposed by the curve equation), and a private key d (an integer mod p) corresponds to the public key D = G+G+...+G (d terms), written as D = d*G (or shorter: dG), again is a point on the elliptic curve, D = (x,y). Since the size of p is moderate, a fixed-size encoding of d as well as x and y is used; in DNSKEY RRs, the EC public key is stored as the concatenation x|y. These details only matter for the key generation, signing, and signature verification; administratively, in the DNS keys for the defined EC groups are binary blobs of 2*32=64 or 2*48=96 octet length, respectively. ECDSA signatures (just like DSA signatures) also are pairs of integers, denoted as (r,s), but conceptionally they are independent field elements, not EC group points. For uniformity, the signatures are encoded as the concatenation of two fixed-size integers, in the same way as the public keys; again, for the DNS database and the DNS wire protocol, the internal structure doesn't matter, RFC 6605 ECDSA signatures are fixed-size 64 / 96 octet binary blobs. Regarding size and strenght, perhaps over-simplifying the argument: Because EC points are _pairs_ of such mod-p numbers and the arithmetics defined on these pairs looks rather complicated (but nevertheless can be implemented very easily), you can restrict yourself to much shorter numbers than needed for RSA (or DSA, for the matter) -- which operate on single numbers with scalar modulo arithmetics only -- for comparable "strength". In all these cases, "strength" means the complexity of solving the discrete logarithm problem over the respective groups. For ECC, the fixed primes and the other group parameters can be (and actually are) chosen to yield groups that are not susceptible to the known potential attack vectors on the discrete logarithm problem, and the vetting process was very extensive for the commonly recommended Ellptic Curves; contrary to that, since the primes vary per key for RSA/DSA, you need much headroom for safety. +++++++++++++++++++++++++++++++++++++++++++++++++ Q: In my code I observe the ecdsa generates a different signature every time you resign (with the exact same input). Why is this? Is there some random padding involved? Yes, indeed, ECDSA signatures are "randomized". (Note that this is a property shared between ECDSA and DSA.) But don't use the term "padding"; in crypto parlance, it's better described as using a "salt" -- a random number generated ad hoc and not reused later. See Step 1 in Section 5.4.2 of RFC 6090 (which uses the academical term "KT-I Signature", not the 'branding' term "ECDSA", but it later notes that ECDSA signatures are actually equivalent to these. For convenience, I quote the relevant sections from RFC 6090 below; see the earlier sections of RFC 6090 for the notation; for DNSSEC usage as per RFC 6605, h() is SHA-256 / SHA-384 applied to the to-be-signed part of the RRs, as specified by the DNSSEC RFCs. You might prefer to start reading with s5.4.2 and refer back to the earlier parts as needed. -------- start quotes from RFC 6090 -------- 5.3. KT-IV Signatures [...] The algorithm uses an elliptic curve group, as described in Section 3.3, with prime field order p and curve equation parameters a and b. We denote the generator as alpha, and the order of the generator as q. We follow [FIPS186] in checking for exceptional cases. 5.3.1. Keypair Generation The private key z is an integer between 1 and q-1, inclusive, generated uniformly at random. (See Appendix B regarding random integers.) The public key is the group element Y = alpha^z. Each public key is associated with a particular parameter set as per Section 3.3. [...] 5.4. KT-I Signatures [...] 5.4.1. Keypair Generation Keypairs and keypair generation are exactly as in Section 5.3.1. 5.4.2. Signature Creation To compute a KT-I signature for a message m using the private key z: 1. Choose an integer k uniformly at random from the set of all integers between 1 and q-1, inclusive. (See Appendix B regarding random integers.) 2. Calculate R = (r_x, r_y) = alpha^k. 3. Calculate s1 = r_x mod q. 4. Calculate s2 = (h(m) + z*s1)/k mod q. 5. As an option, one MAY check if s1 = 0 or s2 = 0. If either s1 = 0 or s2 = 0, a new value of k SHOULD be generated and the signature SHOULD be recalculated. (It is extremely unlikely that s1 = 0 or s2 = 0 if signatures are generated properly.) The signature is the ordered pair (s1, s2). Both signature components are non-negative integers. -------- end quotes from RFC 6090 -------- BTW: Methods to "split" private keys, e.g. in support of partial escrow for desaster recovery, also use such randomly selected data, for instance, see the array A in the [TSS] share generation algorithm. (Reportedly, a similar procedure is applied to the Root Zone KSK.) +++++++++++++++++++++++++++++++++++++++++++++++++ Q: What reading should an implementer of ECDSA for DNSSEC consider? A: Below is an annotated list of selected readings on Elliptic Curve Cryptography (ECC) that might be of particular interest for implementers of ECDSA for DNSSEC according to RFC 6605. The references below are to readily online available resources only, with the exception of the two hardcover books near the end of the list. First of all, there is RFC 6605: * [RFC6605] Hoffman, P. and Wijngaards, W., "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, April 2012. - general information: http://www.RFC-Editor.org/info/rfc6605 - the RFC text: http://www.RFC-Editor.org/rfc/rfc6605.txt * follow the references, some of which are detailed below! For concise background information on Elliptical Curve Cryptography in general, the underlying arithmetics, and citations to original publications, in IETF style, I really, really highly recommend studying RFC 6090: * [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. - general information: http://www.RFC-Editor.org/info/rfc6099 - the RFC text: http://www.RFC-Editor.org/rfc/rfc6099.txt * relevant sections: 1-3, 5 excluding 5.3.2 and 5.3.3, 6, 7 excluding 7.1, 8 excluding 8.1, 9, 10 - Errata: http://www.RFC-Editor.ORG/errata_search.php?rfc=6090 * please read! In a nutshell (but IANAL [I am not a lawyer] !), this document shows that all we need for this kind of ECC (based on finite fields of prime order) and its implementation for DNSSEC can be based on scholarly publications that partially date back decades and certainly the much-feared patent applications that try to claim to cover the matter, and on highschool/low-level college mathematics (cf. [AoCP2] below). o Standards for Efficient Cryptography Group (SECG) Many details on practical ECC are specified in the SECG documents (initial versions published in 2000). In particular, the low-level conventions (in particular on byte ordering and conversion between data types) adopted by ANSI, IEEE, NIST, and other national standards are described therein. * These are published by an Industry Consortium, SECG: http://www.secg.org/ - Documents http://www.secg.org/index.php?action=secg,docs_home * Standards for Elliptical Curve Cryptography: - SEC 1: Elliptic Curve Cryptography, Version 2.0; SECG / Certicom Research, January 2010. http://www.secg.org/download/aid-780/sec1-v2.pdf * relevant sections: 1, 2., 2.1 excluding 2.1.2 and 2.2.2, 2.3, 3, 3.1 excluding 3.1.2, 3.2, 3.5, 3.10, 3.11, 4, 4.1, A, B, B.1, B.2 (only subparts corresponding to above parts of s3), B.3, B.6 - SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0; SECG / Certicom Research, May 2009. http://www.secg.org/download/aid-784/sec2-v2.pdf * relevant sections: 1, 2.1, 2.4.2, 2.5.1 o NIST Of course, NIST is a major driving force in Standardization. Here are the most important resources: * NIST Computer Security Division | - Computer Security Resource Center | Digital Signatures http://csrc.nist.gov/groups/ST/toolkit/digital_signatures.html * The ECDSA Digital Signature Algorithm has been included in the current (3rd) edition of the DSS: - FIPS 186-3, Digital Signature Standard (DSS) http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf - Recommended Curves White Paper http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf * NIST's DNSSEC recommendations: - NIST Special Publication (SP) 800-81 Rev.1, "Secure Domain Name System (DNS) Deployment Guide", April 2010 http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf o Computer Arithmetics and Random Numbers Many concepts for computer arithmetics, including the kind needed for ECC, and possible optimizations in their implementation, have been investigated, shown, and proven in Donald Knuth's 2nd Volume of "The Art of Computer Programming", first published in 1968. My copy is: * [AoCP2] Donald E. Knuth, The Art of Computer Programming, Volume 2, Seminumerical Algorithms, Addison-Wesley, 2nd ed., 1980. ISBN-10: 0-201-0382206 o The ECC "Bible" - [HEC] Henry Cohen, Gerhard Frey (editors), Roberto Avanzi, Christoph Doche, Tanja Lange, Kim Nguyen, and Frederik Verkauteren; "Handbook of Elliptic and Hyperelliptic Curve Crytography"; Chapman & Hall / CRC, 2006; ISBN-10: URN:ISBN:1-58488-518-1 , ISBN-13: URN:ISBN:978-1-58488-518-4 NOTE: Here you'll find all the math and background, including proofs for optimized algorithms (sound mathematical background needed), and a *huge* bibliography (may be interesting for defense against patent claims) Finally, supplemental to the 'BTW' Note above: o Threshold Secret Sharing (TSS) - [TSS] Internet-draft (expired work in progress) http://tools.ietf.org/html/draft-mcgrew-tss-03 (this section shows use of random numbers in share generation: http://tools.ietf.org/html/draft-mcgrew-tss-03#section-3.2 ) +++++++++++++++++++++++++++++++++++++++++++++++++ --ELM1334330683-28173-0_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --ELM1334330683-28173-0_-- From dnsext-bounces@ietf.org Fri Apr 13 08:30:39 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1CC21F87D1; Fri, 13 Apr 2012 08:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334331039; bh=jKLyKI8JujvFVOepvWuyKbyPsTvNBN9VuTz5cwjOe50=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=LfUfW6+8pamswEHatbfNYIWEQU0mvWdTFVY6bZCok6cjRGRVPgJkOE7ba1AJo88Zv 0dC8qNhDHRR8C7yPaVt5wKDnqDe0gbt6+ULRwb1+en/kIhjxoiIrtPM2RWGnYIjnr6 DHFVnwZKT+EqXPy0qjTNHLNaX3E1xNu0E3zZSbhw= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DAF21F87CB for ; Fri, 13 Apr 2012 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCbbj9YCDHlX for ; Fri, 13 Apr 2012 08:30:36 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BEBBD21F8675 for ; Fri, 13 Apr 2012 08:30:13 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BC80F1ECB41C; Fri, 13 Apr 2012 15:30:12 +0000 (UTC) Date: Fri, 13 Apr 2012 11:30:15 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120413153000.GB46538@mail.yitter.info> References: <201204131524.RAA28225@TR-Sys.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <201204131524.RAA28225@TR-Sys.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] informal publication space (was: RFC 6605 (ECDSA in DNSSEC) -- Q & A) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Q29sbGVhZ3VlcywKCk9uIEZyaSwgQXByIDEzLCAyMDEyIGF0IDA1OjI0OjQzUE0gKzAyMDAsIEFs ZnJlZCBIw7ZuZXMgd3JvdGU6Cj4gSSB0cnkgdG8gc2VuZCBteSBjb250cmlidXRpb24gYXMgYSAu dHh0IGF0dGFjaG1lbnQuICBJZiBkZXNpcmVkLAo+IHRoZSBDaGFpcnMgY291bGQgaW5jbHVkZSB0 aGlzIG1hdGVyaWFsIGludG8gdGhlIFdHIHdpa2kuCgpUaGlzIGlzIGFuIGludGVyZXN0aW5nIHN1 Z2dlc3Rpb24sIGJ1dCBpdCBzdHJpa2VzIG1lIGl0IGNvbnRhaW5zIGEKY2hhbGxlbmdlIHRvIHVz OiB3aGVuIHRoZSBXRyBjbG9zZXMgZG93biwgdGhlIHdpa2kgYW5kIGFsbCB0aGUgb3RoZXIKdG9v bHMgcGFnZXMgZ28gYXdheS4gIAoKVGhpcyBvbmNlIGFnYWluIHN1Z2dlc3RzIHRvIG1lIHRoYXQg d2UgbmVlZCB0byBmaW5kIGEgcGxhY2UgdG8gcHVibGlzaAp0aGlzIGtpbmQgb2YgaW5mb3JtYWwg bWF0ZXJpYWwuICAKClN1Z2dlc3Rpb25zPwoKQmVzdCwKCkEKCgotLSAKQW5kcmV3IFN1bGxpdmFu CmFqc0BhbnZpbHdhbHJ1c2Rlbi5jb20KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KZG5zZXh0IG1haWxpbmcgbGlzdApkbnNleHRAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNleHQK From dnsext-bounces@ietf.org Fri Apr 13 08:39:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9B21F87D7; Fri, 13 Apr 2012 08:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334331597; bh=dxr0EAcY+Cs5WTyOiUgoh+Ysyf+9r9Ip1JFNO+9609w=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=NS4O/nR6WxU6RqpIHaliyUgmXDxRJgdg0n55LMwFtKVhiHtUhmd270kJX/7WSrbmR tO+IfTLa/K5eD6IszeGGAhZZTn2mZgUH8OkY+j++ZHeU6smjvoEq1/brY/PQM9pBts WMJRmTwB8GXKv83oWim+7Z64uaVceXJRdc0kdHY8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500F621F869C for ; Fri, 13 Apr 2012 08:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcREDMGgykfe for ; Fri, 13 Apr 2012 08:39:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CCB8A21F8697 for ; Fri, 13 Apr 2012 08:39:55 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3DFdr8W020824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2012 08:39:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120413153000.GB46538@mail.yitter.info> Date: Fri, 13 Apr 2012 08:39:53 -0700 Message-Id: <0B3BA9CF-AD1F-47B0-B4AA-79C63EC89770@vpnc.org> References: <201204131524.RAA28225@TR-Sys.de> <20120413153000.GB46538@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dnsext@ietf.org Subject: Re: [dnsext] informal publication space (was: RFC 6605 (ECDSA in DNSSEC) -- Q & A) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Apr 13, 2012, at 8:30 AM, Andrew Sullivan wrote: > Colleagues, > = > On Fri, Apr 13, 2012 at 05:24:43PM +0200, Alfred H=F6nes wrote: >> I try to send my contribution as a .txt attachment. If desired, >> the Chairs could include this material into the WG wiki. > = > This is an interesting suggestion, but it strikes me it contains a > challenge to us: when the WG closes down, the wiki and all the other > tools pages go away. = > = > This once again suggests to me that we need to find a place to publish > this kind of informal material. = > = > Suggestions? Informational RFCs. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 13 09:18:02 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC36721F87DF; Fri, 13 Apr 2012 09:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334333882; bh=fXDo3lC4+sAPycl8NQEjN9SbB7p3u1Euqd6rAab5sew=; h=Message-Id:From:To:In-reply-to:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=cNjMOtagQinMuHFrXXos+FaXbNR0wXQwSMVrggX5eTho93uI1uwOxk5cNk1CooZRR YJLLx8k814TCFtSncNulRaSuhiA6r9+zkbuJ22GyiOMAWdpQWq4wXIpcG3XSMKQC8L DOLd7Qux5YmCli8jtZgaj/6wA37olcTkH2m5G56o= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F93121F87DF for ; Fri, 13 Apr 2012 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE-C03pQUrRz for ; Fri, 13 Apr 2012 09:18:01 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 663A021F8629 for ; Fri, 13 Apr 2012 09:18:01 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3DGHxUO040512; Fri, 13 Apr 2012 18:17:59 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204131617.q3DGHxUO040512@givry.fdupont.fr> From: Francis Dupont To: Alfred =?hp-roman8?B?SM5uZXM=?= In-reply-to: Your message of Fri, 13 Apr 2012 17:24:43 +0200. <201204131524.RAA28225@TR-Sys.de> Date: Fri, 13 Apr 2012 18:17:59 +0200 Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 6605 (ECDSA in DNSSEC) -- Q & A X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In your previous mail you wrote: > DNSEXT folks, in particular prospective implementers, => I have two comments about this: - first in fact it is not for DNSSEC implementers but more for implementers of the crypto used in DNSSEC. Note it is not a concern, IMHO it is better to know much than less. - the incentive is very USA centric. Russia (cf GOST) and France at least support the use of ECC too (of course references are in national languages, so not in english :-). Thanks Francis.Dupont@fdupont.fr _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 13 09:27:59 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5595921F8697; Fri, 13 Apr 2012 09:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334334479; bh=HnObDNFpiWtlrPafXAmVAERL7wEo0342/6yUdRaeDPY=; h=Message-Id:Date:To:From:In-Reply-To:References:Mime-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=x1g+r/vEZKUol4Znn19+tHpKm9NR2cgoVn/HmWJGK5/2+k4jwUAAt4ztNFthbaEsz Idh/WjS1qXiIS0Z6ksyJtSOaACv3ZP5pB3rDYDDIdKcYoSdlK9jXnN9J1npnvT4prQ ZCiRBUCyYjCz+sev3XNAdafcm25xV/ICXDJQ1V2Y= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB421F8697 for ; Fri, 13 Apr 2012 09:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7uiBvEIyxKZ for ; Fri, 13 Apr 2012 09:27:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C688D21F867F for ; Fri, 13 Apr 2012 09:27:56 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3DGRn07013262; Fri, 13 Apr 2012 09:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334334475; i=@resistor.net; bh=L0qfHihmzN9DST56yscSpaSTjZNZWUtLEvowaM+62L0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=V1CxoJBFuDQ9oiywVVZ29tKh8PQ0eE7Exie7mpmHP6Y8ET9+SqhXzDAZvCdZp7zv1 z2cYcl3e0sFuXZ/FVZ4mWz1GTDzuOogS+FkyzSWERssQpRohZ9/0dJIC3zB+0V2Vyg A6QRxyUn/HAI61dRfI2XUxJRfgjJywagdiIY7r2U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334334475; i=@resistor.net; bh=L0qfHihmzN9DST56yscSpaSTjZNZWUtLEvowaM+62L0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sGJxR5qk3oiifDMbiv0M3d+tULw+PCmPXZfL2igc2+9vVA9dlVtdI3V/ndayoiZTe Mza0hNox9JhyWfe73YtRFpnYx+8TPhCU3L8DrQDo4ACbTkM68D75fGzdUX8IBA57g7 6a+TxO5a4cO72NOAX1hrmTzkG7Xav8CirA9FwEbQ= Message-Id: <6.2.5.6.2.20120413091315.0aa77430@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Apr 2012 09:20:13 -0700 To: Alfred From: SM In-Reply-To: <201204131524.RAA28225@TR-Sys.de> References: <201204131524.RAA28225@TR-Sys.de> Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 6605 (ECDSA in DNSSEC) -- Q & A X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Hi Alfred, At 08:24 13-04-2012, Alfred wrote: >I have had some off-list conversations on ECDSA for DNSSEC >and have been encouraged to make the material available and >somehow linked to the just published RFC 6605. As a Friday 13th comment, if you want to make the material somehow linked to RFC 6605, you can file it as an errata. >I try to send my contribution as a .txt attachment. If desired, >the Chairs could include this material into the WG wiki. It's easier to post this as an I-D. If people find it useful at some point, it shouldn't be that difficult to get it published as a RFC. Regards, -sm _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 13 09:32:40 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A71621F862F; Fri, 13 Apr 2012 09:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334334760; bh=pTgaZBYAW1LXBMVrqb4PWjNBay35uFNFmQCgYrOIUPM=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Y3Bwtmox9EtYb/HfukqX2S+nWJIvbnV38E8jXeYv2yGB9IKLfaAaxs2OH16wKQ0yz HXo6FveW26QHfhtvsM9ewyztcCg/i6CT7NhG9hPBwTuo/yGiQs0t2DoEOjhQXpf+cp Ui4HF4M+Muw5XOF6LTeLK8KEu9ryLIzUhArrlayU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFC21F8629 for ; Fri, 13 Apr 2012 09:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-2aWKNw5B18 for ; Fri, 13 Apr 2012 09:32:38 -0700 (PDT) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1BC21F85D9 for ; Fri, 13 Apr 2012 09:32:38 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id E53EF40020; Fri, 13 Apr 2012 18:32:36 +0200 (CEST) Date: Fri, 13 Apr 2012 18:32:36 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120413163236.GA32741@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <201204131524.RAA28225@TR-Sys.de> <6.2.5.6.2.20120413091315.0aa77430@resistor.net> MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20120413091315.0aa77430@resistor.net> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] RFC 6605 (ECDSA in DNSSEC) -- Q & A X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8986140411713167920==" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org --===============8986140411713167920== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [dnsext] RFC 6605 (ECDSA in DNS..." ] > As a Friday 13th comment, if you want to make the material somehow > linked to RFC 6605, you can file it as an errata. >=20 > >I try to send my contribution as a .txt attachment. If desired, > >the Chairs could include this material into the WG wiki. >=20 > It's easier to post this as an I-D. If people find it useful at some > point, it shouldn't be that difficult to get it published as a RFC. This faq was very enlightening for me. If Alfred chooses to go the I-D rout= e,=20 I hereby volunteer myself as (a second) editor -- if needed/wanted. Regards, --=20 Miek Gieben --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+IVSQACgkQJYuFzziA0Pb/4wCgqRN9GheTTbw71s8SvfXC1iYC /UUAn3w/WMJay3uLcnpo5frksRVdyTxD =KbMX -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- --===============8986140411713167920== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --===============8986140411713167920==-- From dnsext-bounces@ietf.org Fri Apr 13 11:03:21 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5B711E80B8; Fri, 13 Apr 2012 11:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334340201; bh=Fm1A0AjMH3mqEYFb6UnFBx3vk5Nh26cE6VwzB21jjAY=; h=To:From:Message-Id:Date:Cc:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:MIME-Version: Content-Type:Content-Transfer-Encoding:Sender; b=OO81HnFRchfwxN7AygUVGgd/W2Ub3UF1X9Knt0DiWbAlGujGAwBrZkMogV/OXsRFU zio7K8gRTaID0Kv8Jl3qpYsMrUGFCq/FvBovG3NNH2neBdKuqQGhLHYu01IrdtRgQO P9+108hxGu6O4JVsyEkEoF15wsSdwfENKU1TPN50= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4411E80A2; Fri, 13 Apr 2012 11:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.176 X-Spam-Level: X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHuekuHdocYi; Fri, 13 Apr 2012 11:03:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D312D11E809C; Fri, 13 Apr 2012 11:03:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C4C4AB1E002; Fri, 13 Apr 2012 11:02:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120413180224.C4C4AB1E002@rfc-editor.org> Date: Fri, 13 Apr 2012 11:02:24 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] RFC 6604 on xNAME RCODE and Status Bits Clarification X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 6604 Title: xNAME RCODE and Status Bits Clarification Author: D. Eastlake 3rd Status: Standards Track Stream: IETF Date: April 2012 Mailbox: d3e3e3@gmail.com Pages: 5 Characters: 10790 Updates: RFC1035, RFC2308, RFC2672 I-D Tag: draft-ietf-dnsext-xnamercode-00.txt URL: http://www.rfc-editor.org/rfc/rfc6604.txt The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. [STANDARDS-TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 13 12:17:58 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E9911E80E2; Fri, 13 Apr 2012 12:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334344678; bh=UYqtq/EHt8ill5EjEzs6GJqLeBfT1gxKC+PLIdFx5Wk=; h=From:Message-Id:To:Date:In-Reply-To:Mime-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=CKVSLgVhzgIpfGFpugDHt/X2qPwTAKLpYtz8PoXmI4xksbLdddVPtupKJMxYetKYG 61QHwPTxv/v2uzr163XeQUKBpbdRzReDjj4zwj1XQGKDN9xKj/F3Erj9+4p5SnfmU9 O67hMlf+k0uMfbsHUiA4nd/SViL10gjJe1CtimH8= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2511E80E2 for ; Fri, 13 Apr 2012 12:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.867 X-Spam-Level: X-Spam-Status: No, score=-97.867 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxNQGb-GSeSz for ; Fri, 13 Apr 2012 12:17:56 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8997811E80E0 for ; Fri, 13 Apr 2012 12:17:54 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA072444539; Fri, 13 Apr 2012 21:15:39 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA29177; Fri, 13 Apr 2012 21:15:37 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204131915.VAA29177@TR-Sys.de> To: sm@resistor.net Date: Fri, 13 Apr 2012 21:15:36 +0200 (MESZ) In-Reply-To: <6.2.5.6.2.20120413091315.0aa77430@resistor.net> from SM at Apr "13, " 2012 "09:20:13" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 6605 (ECDSA in DNSSEC) -- Q & A X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org SM, thanks for your heads-up toward write-up in an I-D! ... > Hi Alfred, > At 08:24 13-04-2012, Alfred wrote: >> I have had some off-list conversations on ECDSA for DNSSEC >> and have been encouraged to make the material available and >> somehow linked to the just published RFC 6605. > > As a Friday 13th comment, if you want to make the material somehow > linked to RFC 6605, you can file it as an errata. > >> I try to send my contribution as a .txt attachment. If desired, >> the Chairs could include this material into the WG wiki. > > It's easier to post this as an I-D. If people find it useful at some > point, it shouldn't be that difficult to get it published as a RFC. > > Regards, > -sm I'm considering ... but I need to focus my time available on other work first, so other contributors are invited to step in. Miek Gieben noted on this thread: > This faq was very enlightening for me. If Alfred chooses to go > the I-D route, I hereby volunteer myself as (a second) editor -- > if needed/wanted. You are welcome, of course, to take the lead! Maybe other implementers of DNSSEC software components have more questions, answers, and/or comments. There's a salt of grain, however, in SM's remark: "shouldn't be that difficult to get it published as a RFC" might not apply because there's still the ban for detailed URIs in RFCs, and I assume that the references given in my posting are a valuable part that would be missed in an RFC. So I'll observe upcoming feedback for some time and return to the topic of deciding on an I-D in May. To Andrew Sullivan's remark: > This once again suggests to me that we need to find a place > to publish this kind of informal material. > > Suggestions? I doubt the DNSEXT related IETF Tools pages will die with the WG; like expired I-Ds, more likely some pages will be kept on the graveyard of immortals at http://tools.ietf.org/wg/concluded/ , which links to the WG home pages with URIs as before (e.g., I just discovered there are still full-fledged DNSIND and DNSSEC status pages at http://tools.ietf.org/wg/dnsind/ and http://tools.ietf.org/wg/dnssec/ ); but admittedly, maintenance might become a serious problem. Maybe DNSOP folks could provide a more permanent home in the IETF for DNS implementation related resources, so maybe the DNSOP wiki might be a candidate. Best regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 16 09:44:51 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E009D11E80AC; Mon, 16 Apr 2012 09:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334594691; bh=cl4u2m1goTHlE7Hj8ZU/jiVePOP/j5KSGenUFtUMHmg=; h=MIME-Version:From:Date:Message-ID:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ooWXA8wUayCBE9qUGWYKBK5Fdb2v/cgFEe+Nx6Xk2qhKnEsEbIZuMQWSQnA0njdqa p2DsZ5vjWt1pE1ueqS2L4v8gRylF5IiYpnoSkcDIabovu7j1pjsqR8Zy2z8Gzi6DbK ztIRHYZrHzW75hpQECfsP/LFMKl5ONtfhFx2oC9s= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE2711E80AC for ; Mon, 16 Apr 2012 09:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.149 X-Spam-Level: X-Spam-Status: No, score=-104.149 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKAt1hY4gGvk for ; Mon, 16 Apr 2012 09:44:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2357A11E80A6 for ; Mon, 16 Apr 2012 09:44:36 -0700 (PDT) Received: by lbbgf14 with SMTP id gf14so2258227lbb.31 for ; Mon, 16 Apr 2012 09:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=3Iqgp89SP4o7kQA41u3tUDpDbfCYPVeRit8PV5VezRc=; b=AaH7tK5xcCRG9HiE2XXXeHSa5EXF5DAt5mEy81sW/Q7rHkLqEc1tVIZPwCSDF/Zdxo eUJulrSdT/85JXmHZkcvmd+OGJls8Xhiz0ES2LBOue7dbJOlLUKx1XT68wOEeF2Zv/hH QtmcNpdR/yR7S7unFgiynVnRYImIdCz11U3844OYY7z4u9JM2DWcdqi5Sb2fLKFBz3il Uazed6Io+PJve4dpcL2G/92TPsGa8bJzcwHuT76tSSimjM+g8Ydzj12YSiquwxtin+5t sfOvBwZoZJuz4ZqOsMC60AhI9UcpoSAPNw+MYqOWLbIEKZE7SmRirBoBP1E88Yidy21x oDqQ== Received: by 10.152.146.234 with SMTP id tf10mr10941070lab.31.1334594676108; Mon, 16 Apr 2012 09:44:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.162 with HTTP; Mon, 16 Apr 2012 09:44:15 -0700 (PDT) From: Donald Eastlake Date: Mon, 16 Apr 2012 12:44:15 -0400 Message-ID: To: IETF DNSEXT WG Subject: [dnsext] draft-ietf-dnsext-6195bis X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Hi, Unless someone objects, I plan to make the following changes: In Section 3.1.1, add a few words so "... IANA appoints an Expert and sends= the completed template to the Expert." would read "... IANA appoints an Expert and sends the completed template to the Expert copying the applicant." And add a sentence to Section 5, right after the first sentence of the 2nd paragraph saying "IANA forwards the template to the Expert copying the applicant." Also, in Section 3.1.1 change where it says the Expert makes their decision "informing IANA and the applicant" to "informing IANA, the applicant, and the dnsext@ietf.org mailing list". Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 16 12:59:39 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811F21F86E8; Mon, 16 Apr 2012 12:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334606379; bh=J+F/ZQ9Bb09AKUL0sLLtgVY5Pq3Su2YoyAHu6vmnk1s=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=gJiCR7ipSWPWC4q2HmY9cbx8I41ULi+ZQebvBXKn0wfyW0TZ9+q4cvtm6YlPrW4VQ DCraGN0mEnUIeIvsHKCz8EytUzGEgzyyadYXriyD52c2sAN0M1hiweRtAqfIG93lzT yvInQpIK9j+NPelYfGy7tAlO4lqdBin1u/Q+uilM= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C221921F86E8; Mon, 16 Apr 2012 12:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn46Qw5XJqkO; Mon, 16 Apr 2012 12:59:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7221F86E4; Mon, 16 Apr 2012 12:59:37 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 563481ECB420; Mon, 16 Apr 2012 19:59:36 +0000 (UTC) Date: Mon, 16 Apr 2012 15:59:34 -0400 From: Andrew Sullivan To: dane@ietf.org, dnsext@ietf.org Message-ID: <20120416195934.GM49880@mail.yitter.info> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> <4F8C71E6.1010103@ogud.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F8C71E6.1010103@ogud.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] [dane] TLSA == RRtype 52 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org This is really a discussion about an issue for the DNSEXT WG, so it's cc:d there. Follow ups should go there, too, unless they're linked tightly to the DANE issue. I didn't adjust the Followup header because in my experience that never works. On Mon, Apr 16, 2012 at 03:24:22PM -0400, Olafur Gudmundsson wrote: > But the application in this case referenced a particular version of an > Internet draft: Yes. This is why some people have objected to the difficulty of getting the approved templates. The template as in the application is not necessarily what was approved. I think in this case it is, but as we see the registry does not actually preserve the link. > If there are changes in the registries that are created by the ID > that is fine. > Type codes are cheap, interoperability problems are not. Yes. Which is rather a good reason to hesitate to ship code that doesn't have a stable refernence in the registry, if you ask me. > There is code range for experimentations, see RFC6195 section 2.3 > 0x0F01 - 0x0FFF Private Use Yes, I'm perfectly aware of that. The complaint has been that people want to be able to ship things with what they regard as minor differences without having to go through the DNS mafia again. Like it or not (I'm in the "not" camp), people are engineering around our community's intransigence. > Andrew I hate to correct you, the whole point of early allocation > was to avoid having to publish an standards track RFC in order to > get > an RR type code. That could be better achieved by "specification required". Expert review allows us to allocate a type code without any guarantee that the wire format will remain stable. There is exactly one way to guarantee that such a wire format will remain stable, and that is to publish something in an archival series. We have a way to do that: publish an RFC. Requiring conformance with RRTYPE application templates or anything else is nonsense, because the references aren't stable. This is in fact a much more serious example of the same fight we had when we tried to be clever with the registry in the registry-fixes attempt some time ago. (In that case, I happened to think we were right, but the objection rested on the same foundation: if you want a stable reference, put it in an RFC.) > what is wrong with using 0xf?? values for that ? > > all you need to do is to send a email to the wg mailing list saying > "I want to do an experiment and we will use code X here is my format." > the private RRtype either contains version number or you roll the > code each time there are wire format changes. In this case only > consenting implementations are at risk. Nothing, of course. I have no idea why people even want RRTYPE assignments prior to publishing an RFC with the specification, but people do. > If a simple building block like DNS record format needs to change > during IESG review, the whole WG effort is suspect and it should be > sent to back to the drawing board. I fully agree. But it is one thing to say, "This sure hadn't better change. If it does, something is really wrong," and quite another to say, "This can't possibly change." Best, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 16 14:55:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0658011E809C; Mon, 16 Apr 2012 14:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334613357; bh=xEPx/ZXJ1kKgZnWg+AD/kFMhIp8h1z5XylIOnwPDmAo=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=uW3pz4dW+0t/2AF0ndhDt7GGpC+/rsxaZrbFvUtNnjhR73FoaY7GURfS7A3XgnH4y e23UNe6lyc/OC9s4qzgY0tjvtWHA5UN3n1Y8mFfbyv8pWQ427A1mTc6WTuoPij1JNy 35BGUZmbJmBfU0elryCnKtHtsmBGq+mAfjGAmYLo= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F04711E809C for ; Mon, 16 Apr 2012 14:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8TRfkNEpsuZ for ; Mon, 16 Apr 2012 14:55:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F06211E807F for ; Mon, 16 Apr 2012 14:55:54 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3GLtr5Q045413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 16 Apr 2012 14:55:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120416195934.GM49880@mail.yitter.info> Date: Mon, 16 Apr 2012 14:55:53 -0700 Message-Id: <0F55A6EF-643F-4145-A54F-5D85D415C7A2@vpnc.org> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> <4F8C71E6.1010103@ogud.com> <20120416195934.GM49880@mail.yitter.info> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1257) Subject: Re: [dnsext] [dane] TLSA == RRtype 52 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org > On Mon, Apr 16, 2012 at 03:24:22PM -0400, Olafur Gudmundsson wrote: >> But the application in this case referenced a particular version of an >> Internet draft: We applied in good faith, assuming that our application was for the protocol, not a single draft. If the DNSEXT WG chairs felt that we should wait until the draft could not have any wire changes, the DNSEXT WG chairs should have told us that at the time of the application. The registration at IANA does not name the draft; it lists the name for the DANE WG chair who applied for code point. A sensible interpretation of that is "the person who is named gets to decide what the code point means", not "go ask that person which draft he applied for". If given a choice between what one co-chair and IANA thinks, versus the other co-chair, I hope most people pick the former. This would not be an issue if a DNSEXT co-chair (Olafur) had not exhorted people to implement using the assigned code point even though the spec is not stable. In that message, he (wisely) did not say "implement only the -18 draft, and we might screw you over later if the spec changes". Most developers care about implementing a stable spec. The spec will be stable when the IESG sends it to the RFC Editor, hopefully in a few weeks. If a developer wants, they can use the code point now; nothing stops them other than the desire to ship stable code. --Paul Hoffman _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 16 15:32:26 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4B21F85B7; Mon, 16 Apr 2012 15:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334615546; bh=qMw47ZiHBljSOJKhQXW+j/yqZmsDFpWE3eKsTzxioHs=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=g+n9aFTufiuFnTtTBvWXVOO84a07VTrZkhuVCv/VM27dC6kUoORooI3JLhxICfgRw ZzULiR5Y6qev9a1pVA0ULFIYj5xavs/78Piuziyr6VURpf0m5SWVIRL+UbKRae690I 4bcqE4WRof75CjfOa4t9OAtyPFcMCtA7cNLIEj7I= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D4A21F85B7 for ; Mon, 16 Apr 2012 15:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.965 X-Spam-Level: X-Spam-Status: No, score=-97.965 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 798Q5E0LTLGV for ; Mon, 16 Apr 2012 15:32:25 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B921F85B6 for ; Mon, 16 Apr 2012 15:32:24 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA087715469; Tue, 17 Apr 2012 00:31:09 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA17996; Tue, 17 Apr 2012 00:31:08 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204162231.AAA17996@TR-Sys.de> To: dnsext@ietf.org Date: Tue, 17 Apr 2012 00:31:07 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [dnsext] RR type IANA requirements discussion X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Regarding the renewed discussion on IANA requirements for RRtype registrations: Please keep in mind what draft-ietf-dnsext-rfc6195bis-00 now says ... a) in Section 3.1.1 (DNS RRTYPE Allocation Policy): IANA shall maintain a public archive of approved templates. In addition, if the required description of the RRTYPE applied for is referenced by URL, a copy of the document so referenced should be included in the archive. b) in the IANA Considearions (Section 5): [...]. IANA archives and makes available all approved RRTYPE allocation templates and referred documentation (unless it is readily available at a stable URI). [...] Isn't that clear enough now and doesn't that satisfy the strong desire of the community to have the registry unambiguously document what actually has been allocated for a new RR type ? Donald told me recently that he thought the 2-week expert review period would suffice because the Expert will check on consistency and completeness of the template and the referred-to documentation and simply will quickly reject the registration request if it doesn't. If changes are needed (e.g. a different mnemonic will be going to be assigned for clarity -- as it has happened), the expert will reject and the applicant will modify the template and documentation and re-submit. A template cannot be approved unless it matches what is going to be registered; that needs to be ensured by the Experts and IANA in the future, isn't it? (I.e., it MUST NOT happen again that the registry entry does not match the template/documentation linked to the registry entry.) Now that the WG prefers a longer period, that doesn't change the procedure -- or did I miss something? Kind regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 16 16:07:57 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A7011E80AF; Mon, 16 Apr 2012 16:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334617677; bh=IJ0CFGPB++2jUX3n+n879Q6jaWFXe4fjwJ1AQePmOnk=; h=Date:From:To:Message-ID:References:MIME-Version:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Dp8G7x0D2eI5Ig/6lFQLEr0aY5ZLu8cJu/6K0SwbTI5OzaZDTR3hBTwRn5Jk/zp3u +HAF3dt3rOOsVIMpYVuDqCdPG/w4pj00P7Sd5bfjSGILQgtls9Jb3o11ld+CdndwJ0 huyKsLs9VCtITr9JP604q79tVUFAhxHLIFuBSRrs= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9102B11E80AF for ; Mon, 16 Apr 2012 16:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OiKIwfwvFZe for ; Mon, 16 Apr 2012 16:07:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 12DDB11E807F for ; Mon, 16 Apr 2012 16:07:55 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F23A51ECB41D for ; Mon, 16 Apr 2012 23:07:54 +0000 (UTC) Date: Mon, 16 Apr 2012 19:07:42 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120416230742.GA52952@mail.yitter.info> References: <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> <4F8C71E6.1010103@ogud.com> <20120416195934.GM49880@mail.yitter.info> <0F55A6EF-643F-4145-A54F-5D85D415C7A2@vpnc.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0F55A6EF-643F-4145-A54F-5D85D415C7A2@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] [dane] TLSA == RRtype 52 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A small process nit On Mon, Apr 16, 2012 at 02:55:53PM -0700, Paul Hoffman wrote: > > We applied in good faith, assuming that our application was for the protocol, not a single draft. If the DNSEXT WG chairs felt that we should wait until the draft could not have any wire changes, the DNSEXT WG chairs should have told us that at the time of the application. > The management of RRTYPE allocation is not up to the DNSEXT chairs, perhaps surprisingly. The expert review and assignment rules happen to use an expert panel that involves one of us (me) for administrative convenience, and happen to use this mailing list for discussion. But as a formal matter, the WG's opinion about a draft is not taken into consideration, and there is no formal process link to the WG. We picked the dnsext WG's list in the past on the general principle that the WG's list is likely the place where people interested in these things can be found. Indeed, had we not completely lost access to moderation and so on, we might well have left the list name as namedroppers@ops.ietf.org. Again, I think this is all a formal matter. Naturally, if a large number of people on this list expressed reservations about an allocation, the expert would no doubt take that into consideration. (For similar reasons, I do not actually believe that there will be any change in the wire format of the RRTYPE when it goes through the IESG. As a practical matter, the wire format is almost certainly stable. As a formal matter, though, we cannot assume that.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 16 16:17:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DC411E80D1; Mon, 16 Apr 2012 16:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334618262; bh=4ZmH/MYVK3jYXxUC/ZNzx8H23fz//sbQTKAGiPixtV8=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=pS00ibYAcWv0rURSsFeRBOW2+nhtrO8OMNKs3saQB2BwWN1tOidaAGeRJCZ4a6E+V Q6mlKK1W24UPbYP2veouxDJI8LlxVRpoS4GY+CferYW6tilToCjqUfe7tM+1BlKY3s NB3JGcMA4YIZ6dhuKfcLlD82sEnBKRKiZXjFjsyc= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606221F8537; Mon, 16 Apr 2012 16:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hTTHCToZHG5; Mon, 16 Apr 2012 16:17:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB621F8539; Mon, 16 Apr 2012 16:17:40 -0700 (PDT) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id C11CD14048B; Tue, 17 Apr 2012 01:17:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334618259; bh=bbI+4UMjSTjAWhZBegLqPdOJXRW0tHif70DUJd2ntvI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References; b=cvga2WnPjrHahppkZuej8NkaKGAH8rX2LX6viVTuEzzz0sEQnHyxaATZYzUoLlxgN jKFrm0hb5Dsxl/IdU5pNwb3987VWVbTykRC/y9E4NDQMbrCXBMIabuBwodqPQW6Ksj kSdCkVpqC8nOQUOVjtWhjkg09sONo29T3oyUjuhg= Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120416195934.GM49880@mail.yitter.info> Date: Tue, 17 Apr 2012 01:17:40 +0200 Message-Id: <2A893CEE-7AA3-403D-BFD6-61F5D69D3802@nic.cz> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> <4F8C71E6.1010103@ogud.com> <20120416195934.GM49880@mail.yitter.info> X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dnsext] [dane] TLSA == RRtype 52 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Ck9uIDE2LiA0LiAyMDEyLCBhdCAyMTo1OSwgQW5kcmV3IFN1bGxpdmFuIHdyb3RlOgoKPiBUaGlz IGlzIHJlYWxseSBhIGRpc2N1c3Npb24gYWJvdXQgYW4gaXNzdWUgZm9yIHRoZSBETlNFWFQgV0cs IHNvIGl0J3MKPiBjYzpkIHRoZXJlLiAgRm9sbG93IHVwcyBzaG91bGQgZ28gdGhlcmUsIHRvbywg dW5sZXNzIHRoZXkncmUgbGlua2VkCj4gdGlnaHRseSB0byB0aGUgREFORSBpc3N1ZS4gIEkgZGlk bid0IGFkanVzdCB0aGUgRm9sbG93dXAgaGVhZGVyCj4gYmVjYXVzZSBpbiBteSBleHBlcmllbmNl IHRoYXQgbmV2ZXIgd29ya3MuCgoKPGRhbmUgY2hhaXIgaGF0IG9uPgpZZXMsIHBsZWFzZSBrZWVw IHRoZSBmdXJ0aGVyIGRpc2N1c3Npb24gb2ZmIHRoaXMgbGlzdC4gIEFuZCBldmVyeWJvZHkKcGxl YXNlIGNvb2wgZG93biBiZWZvcmUgcmVzcG9uZGluZywgb3IgcmF0aGVyIGRvIG5vdCByZXNwb25k IGhlcmUgYXQgYWxsLgo8L2RhbmUgY2hhaXIgaGF0IG9mZj4KCjxwZXJzb25hbCBoYXQgb24+CkZl ZWwgZnJlZSB0byBkbyB3aGF0ZXZlciB5b3Ugd2FudCwgYnV0IHBsZWFzZSBiZSBhd2FyZSwgdGhh dCB3ZSBoYXZlCm5vdCByZWFjaGVkIHRoZSBSRkMgc3RhdHVzIHlldC4gIFNvIHNhbWUgcnVsZXMg YXBwbGllcyBhcyB3aGVuIHlvdSB3ZXJlCnVzaW5nICJleHBlcmltZW50YWwiIGFsbG9jYXRpb25z IGluIHlvdXIgY29kZS4gIEUuZy4gaWYgeW91IGhhdmUgdG9vbHMKd2hpY2ggdXNlZCBUWVBFNjU1 eHgsIHRoZW4gZmVlbCBmcmVlIHRvIHVzZSBUWVBFNTIsIGJ1dCBjbGVhcmx5IG1hcmsKdGhhdCBh cyBleHBlcmltZW50YWwgZmVhdHVyZSwgd2hpY2ggY2FuIGNoYW5nZS4KPC9wZXJzb25hbCBoYXQg b24+CgpPLgotLQogT25kxZllaiBTdXLDvQogdmVkb3Vjw60gdsO9emt1bXUvSGVhZCBvZiBSJkQg ZGVwYXJ0bWVudAogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQog Q1ouTklDLCB6LnMucC5vLiAgICAtLSAgICBMYWJvcmF0b8WZZSBDWi5OSUMKIEFtZXJpY2thIDIz LCAxMjAgMDAgUHJhaGEgMiwgQ3plY2ggUmVwdWJsaWMKIG1haWx0bzpvbmRyZWouc3VyeUBuaWMu Y3ogICAgaHR0cDovL25pYy5jei8KIHRlbDorNDIwLjIyMjc0NTExMCAgICAgICBmYXg6KzQyMC4y MjI3NDUxMTIKIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWls aW5nIGxpc3QKZG5zZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Wed Apr 18 08:13:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3E521F85D5; Wed, 18 Apr 2012 08:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334762032; bh=mT5+26iybdbBqU1jb3NWx303l/xoMubGc5ooCbmp42w=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=lQD+I5bGzcupz8mqT1J9Gz6u5gSsoT3p7VhPX6QyCPrkgdR6SG+W3i8D4dCOOUvMy 7szriEqoAS4NyLNVKqmhF2NokFvpWGzIGGixf6WqJU5TL8/NTwEghybfX497AApUTv zox3U8z2MMfCDdydFz9jQjNFiHKkuU6ZIOBm3E8M= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B013221F85D5 for ; Wed, 18 Apr 2012 08:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.107 X-Spam-Level: X-Spam-Status: No, score=-98.107 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtyN1VS7eyks for ; Wed, 18 Apr 2012 08:13:46 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id C645D21F84E4 for ; Wed, 18 Apr 2012 08:13:45 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA097431950; Wed, 18 Apr 2012 17:12:30 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA28025; Wed, 18 Apr 2012 17:12:28 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204181512.RAA28025@TR-Sys.de> To: dnsext@ietf.org Date: Wed, 18 Apr 2012 17:12:28 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [dnsext] technical errata filed for RFC 1995 (eid=3196/3197) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Recently, Andreas Gustafsson has supplied a DNSIND mailing list thread on RFC 1995 from November 1999 that shows that the technical flaws I had shortly mentioned in the DNSEXT sessions in Maastricht and Prague as a reason to work on a rfc1995bis document already had been pointed out by Andreas in 1999 and have been discussed on dnsind. For the record, I have now filed two corresponding Technical Errata including a short "Historical Note" for clarification of the precedence; see http://www.RFC-Editor.ORG/errata_search.php?rfc=1995 (In the past, the IESG has asked for Errata as an argument that a 'bis' document is needed; so I hope this might help with draft-dnsext-rfc1995bis-ixfr.) Kind regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 18 12:02:16 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FD321F8483; Wed, 18 Apr 2012 12:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334775736; bh=Dc88D75jc1dnGlWdVtYg+4McYWq2MmpVlqTIvhiLM20=; h=From:Message-Id:To:Date:In-Reply-To:Mime-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Vdfdee2XqL0ODCExDPMfwSaIaXDMi9FovRibM1wQEyIXxVRriv8I95xw2I00AcbXX 9DbghMNZxyis367Z0LTZ1HHpIhHW7EABPPLtvY45gpUwm0JVJKLTWBNAAhxTkvzDxf 4ZXceGXMzS+JT6hMOpZ6ggl93xK85+j1mWsHHswM= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D732421F844D for ; Wed, 18 Apr 2012 12:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.161 X-Spam-Level: X-Spam-Status: No, score=-98.161 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+683Gxar0Ss for ; Wed, 18 Apr 2012 12:02:10 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7C66721F8476 for ; Wed, 18 Apr 2012 12:02:09 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA098815621; Wed, 18 Apr 2012 21:00:21 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA29701; Wed, 18 Apr 2012 21:00:20 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204181900.VAA29701@TR-Sys.de> To: lubos.slovak@nic.cz Date: Wed, 18 Apr 2012 21:00:19 +0200 (MESZ) In-Reply-To: from =?hp-roman8?B?T25kcmVqIFN1crI=?= at Mar "29, " 2012 "05:50:52" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] Review of draft-ietf-dnsext-rfc1995bis-ixfr-00.txt (from Knot DNS team) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Lubos, thanks for your quick review of draft-ietf-dnsext-rfc1995bis-ixfr-00, which has been forwarded to the mailing list by Ondrej Sury on 29 Mar 2012, 17:50:52 +0200 (message archived at http://www.ietf.org/mail-archive/web/dnsext/current/msg12399.html ). Inline below I note the actions taken so far on your suggestions, in my working copy of the draft. The next draft revision is planned to be submitted within a week from now. > Hi, > > I got our head engineer of Knot DNS (Lubos Slovak he's in Cc:), who also > implementor IXFR (from scratch) to review the document and here's the > result (copying verbatim, just added references to sections and 'nit' > words): > > 1) section 1.4 - nit: "makes freely use" -> s/freely/free It actually was intended to say: "freely makes use of ...", and that's what the draft now says. > > 2) Section 2, page 8 - nit: "Therefore, is becomes apparent" -> s/is/it Fixed. > > 3) Section 2, last paragraph - why has to RRSIG(SOA) [to] follow > the SOA in the AXFR-fallback example? Actually, there's no "MUST" requirement, but it is good practice in AXFR implementations to group RRsets together in AXFR responses, and, according to the base DNSSEC specs, the RRSIG(SOA) conceptionally is part of the SOA RRset (except in the context of a query for RRSIG, which does not apply here). However, server implementations have found it convenient to send RRsets as contiguous groups within AXFR responses (because of the manner they are stored, for grouped inclusion in ordinary DNS responses); similarly, for clients that choose to perform detailed plausibility checks of received zone content before serving a new version of the zone data, checking of consistency likely will comprise a check for equality of TTL values within RRsets (Section 5.2 of RFC 2181), and maybe even RRSIG verification, it is beneficial to receive the RRs of RRsets grouped together (so that common DRAM cache replacement algorithms make it much more likely to find the related RRs in the most high-speed memeory comonents present in the system, and hence processing will be much faster). Since IXFR is all about speed and optimization of the zone synchronization process, such server behavior is very desirable in IXFR implementations as well. Taking this into account, I have tentatively modified the draft text to now say: "In contrast, in the case of fallback to AXFR, the IXFR response would typically convey, in order:" ^^^^^^^^^^^ But if implementers do strongly prefer to have IXFR clients find RRsets grouped together, or at leaest to have the RRSIG(SOA) RRs always be placed at the beginning (in the case of IXFR fallback to AXFR), we could make the RR order shown in the draft mandatory (SHOULD or MUST) for IXFR servers. Opinions from other implementers? > > 4) Section 6.2 - missing RFC2119 language; shoulds and mays are small > caps, is that intentional? The server's purging behavior is difficult to test externally. It is strongly recommended to use RFC 2119 terms sparingly and only in cases where the behavior is needed for interoperability and can be tested by observing externally visible behavior. The mandatory rules on "fallback to AXFR" IMO are sufficient to ensure interoperability, and IXFR-ONLY is dedicated to address efficiency issues that plague deployments in specific circumstances, so the details of IXFR server purging behavior seem to be local to implementations, subject to implementation-specific resource management strategies and resource restrictions, and hence out of the bailiwick of RFC 2119. ( :-) ) However, if the WG feels strong about having more detailed, yet testable, requirements regarding the purging and condensation strategy of IXFR servers (Sections 6.2 and 6.3 of the I-D), the draft of course can be modified accordingly. > > 5) And today new question have arrised: > "What should IXFR client do if it receives incomplete > multichunked IXFR response?" > A) discard whole transfer and start over; > B) save usable chunks (e.g. use data to update zone from sn_o to > sn_o+x, where sn_o+x < sn_n) Section 7.1 already is explicit in saying that an IXFR client "MAY" follow strategy B). In particular, the draft says: |7. Client Behavior | | [...] | |7.1. Zone Integrity | | The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936 | [RFC5936] apply in a similar fashion for IXFR. | | However, during the receipt of an incremental IXFR response, and upon | successful processing of an SOA RR that serves as a sentinel for the | end of any change information chunk, an IXFR client MAY immediately | apply and commit to stable storage the SOA serial number change | described by that chunk (and previous chunks, if not already done). | This operation MUST externally appear as an atomar operation. | | [...] Please revisit the full text in Section 7.1 for the detailed considerations and tell us whether that is sufficient. > > Ondrej on behalf of Lubos > > P.S.: Our Knot DNS team (different people than one of the authors of > this document) will do a full review in WGLC. Thanks in advance! I hope that the chairs will proceed to issue WGLC on the upcoming next draft version; experience has show that this is a strong incentive for the WG to take a closer look at the document and commenting on it. > ... > {original draft announcement} Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Wed Apr 18 15:00:55 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DC211E809D; Wed, 18 Apr 2012 15:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334786455; bh=FWoXfEldpXcClVsOUn0qqQ8OWfpmMUk82I3NMuunoOo=; h=From:Message-Id:To:Date:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=rXAvYeeVMkWMQ3j+wmc5HAiMjfTEdI7iZrX7vX/qO8Dsbg9lwtuJm+xxJEpcAQip7 lP0nHqZb+3xYgy1S3hbZdDzp6l1/lHfFWTcLA1DMDZMRHilBDJVp3KXJVWZioxUtjn uHXCvQLc06CtwXUi9bJmgKNpDkFszRGMEtZA62tY= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE7A11E809D for ; Wed, 18 Apr 2012 15:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.206 X-Spam-Level: X-Spam-Status: No, score=-98.206 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKHpTYgzo54g for ; Wed, 18 Apr 2012 15:00:52 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 579CF11E8091 for ; Wed, 18 Apr 2012 15:00:51 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA099566350; Wed, 18 Apr 2012 23:59:10 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA00506; Wed, 18 Apr 2012 23:59:08 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204182159.XAA00506@TR-Sys.de> To: dnsext@ietf.org Date: Wed, 18 Apr 2012 23:59:08 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: [dnsext] draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Note: This thread actually has started on the predecessor individual draft, but to acoid confusion on the target of the discussion, I have changed the Subject to refer to the adopted WG draft, draft-ietf-dnsext-rfc1995bis-ixfr-00. The questions were about the level and detail of the requirements posed onto an IXFR server in packetizing the conceptual IXFR response -- in all the different cases that can occur --, and how thereby the detrimental need for IXFR clients to rely on timeouts (to determine the outcome/state of an IXFR session, under very specific conditions) can be avoided. I have revisited recent messages and previous work, and tried to arrive at the conclusions that look most reasonable and seem to correspond to evolving consensus. Observations and conclusions: (1) IXFR is intended as a more efficient method for in-band zone synchronization than AXFR (for deployment scenarios where it makes sense -- as explained in the draft); therefore, it seems fair that the specification is tailored to support timely, efficient completion of IXFR sessions under most conditions, and that the requirements for IXFR server implementations be at least as strong as the comparable requirements for modern AXFR servers that fully conform to RFC 5936 (excluding the kludges for backward compatibility still supported by that RFC). (2) Updated protocol specifications are not required to still contain specific requirements, or the lack of specific requirements, if that has been identified as a weak point in the protocol. So an updated specification needs to be allowed to specify more specific requirements than its predecessor, but preferably this should be done in a manner that interoperability with legacy implementations is assured as far as it makes sense. Of course, legacy implementations that do not follow the more stringent rules of the revised specification cannot claim conformance to the new specification until they get updated accordingly. But that's the fate of implementations at large, and the DNS world will not be doomed thereby. :-) (3) RFC 5936, Section 2.2 (at the bottom of page 11) specifies: | Each AXFR response message SHOULD contain a sufficient number of RRs | to reasonably amortize the per-message overhead, up to the largest | number that will fit within a DNS message (taking the required | content of the other sections into account, as described below). This was the consensus of the WG two years ago. I conclude -- and that seems to be in line with feedback from implementers -- that, to achieve the performance goal of IXFR, rfc1995bis needs to be *at least* as strong as RFC 5936 in its requirements in Section 3.2.3. Therefore, unless there is strong consensus to the contrary arising quickly, the next draft version will use uppercase "SHOULD" in this context: ! For multi-message IXFR responses, the conceptional answer is split ! into segments that are sent in order. Each segment is comprised of ! an integer number of full RRs, and for transport efficiency, the !> response messages SHOULD be filled up with answer RRs as much as ! possible for the response message size chosen by the IXFR server, ! taking into account the space needed for the other sections in the ! messages. (4) Bulk IXFR runs over TCP, with potentially concurrent transactions for different zones served by the same authoritiative servers. Since the IXFR protocol allows very different kinds of responses (as specified in a fully backward-compatible manner in the draft) the most important kinds of which will consist of multiple response messages, yet does not contain an overall length indication or a specific, generic "end-of-response" indication for multi-message responses, there is a clear need for: * rules that ensure that the kind of response can be determined instantaneously and without ambiguity upon receipt of the first response message; and * rules that clearly allow to determine when a received response message is the last one in an IXFR session. As already indicated in the draft, there are a few specific conditions where the interpreation of an IXFR response cannot be disambiguated until (and if) the next response message arrives, unless IXFR servers are required to packetize their responses in a manner that allows immediate disambiguation at the client. Waiting (in corner cases) for another response message in a given IXFR session in order to eventually determine the status of the response requires the IXFR client to set a timeout and wait -- as a normal protocol operation. All such timeouts are generally regarded as detrimental, and in particular detrimental to the performance optimization we have as a target goal for IXFR. Therefore, unless strong consensus to the contrary arises quickly, the next draft version will contain a more precise description of what conditions indicate the end of an IXFR response, and how the different kinds of IXFR responses are to be disambiguated. But this needs to impose on IXFR servers a very few new, specific, stronger requirements for the packetization of their responses. These conditions already are in the draft, but the text will be revised to distinguish the new requirements and spell out the rationale. The core of this clarification will be a new clause added below the text quoted in (3) above, stating (modulo wordsmithing t.b.d.): ! If an IXFR server intends to send a conceptual IXFR response that ! is comprised of at least two answer RRs, the first two RRs of the ! response MUST be sent in the first response packet to allow the IXFR ! client to immediately distinguish the kind of response coming in. ! An IXFR server MUST NOT send over connection-oriented transport the ! kind of (single-RR) IXFR response that indicates that the server has ! to send a multi-packet response and hence the IXFR request needs to ! be retried over connection-orientend transport (currently: TCP); ! this kind of response is only allowed in response to an IXFR query ! received over connectionless transport (currently: UDP). ! See Section 4 for the details of the various kinds of conceptual ! IXFR responses and how an IXFR client distinguishes these. The verbiage already present in the draft that indicates the necessity to anyway set up timeouts as a safeguard to protect agains fatal conditions will be amended to say that this is also necessary for seamless interoperation with older IXFR servers not conforming to these new requirements, but the efficiency of IXFR operations in specific circumstances will no longer depend on clever heuristics to choose proper values, once the IXFR servers used in a given deployment are updated to conform to the revised specification, since the timeout values then will only apply in fatal cases and can be chosen rather long for resilience reasons without negative effects on normal protocol operation in specific cases. Finally, a closely related topic / question: (5) The example of "fallback to AXFR" in the draft (at the very end of Section 2) currently suggests that, for efficiency at both the IXFR server and the IXFR client, for full zone transfer (fallback to AXFR) an IXFR server (typically) sends the zone RRs grouped by RRset. It has been correctly observed that this ordering does not correspond to a requirement contained in the new AXFR specification, RFC 5936. Should this behavior be recommended/RECOMMENDED in the draft for new IXFR server implementations? Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 19 00:54:12 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3603321F84EC; Thu, 19 Apr 2012 00:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334822052; bh=uMRwF3Qf3Xyj0kaM8OC+6rGaMi1OgEkz8AEymDqepC8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=JoTfbpHN751S3eMZc+MWr0L9OzSQy/08y5Z0EGWp8UeiUv3+VGAMUdUJ1rLQoreLw g8uO8j0zkCoh7+aHfQ0VAlNvvy7d7WkESnpTpfLr0By2AJrxKPw+ozCRo/5D/N9de7 Mk9RKqwjJ3OZPjQuqj8JWrSfeTNA1qEeazYXxpDk= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB0321F84EC for ; Thu, 19 Apr 2012 00:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq4ywrvNj6-D for ; Thu, 19 Apr 2012 00:54:05 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 273A121F8498 for ; Thu, 19 Apr 2012 00:54:04 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q3J7rxZk075421; Thu, 19 Apr 2012 09:54:00 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1334822043; bh=VNzdMX69/YykXeW43LKcJzBi/akShcA5u7hXIs73024=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=BLVBENRt2kwTQOcBrL0KxtT7Q8w8K5T0mDZjqkdFD/HLq53Gc0vvSb8DQqvwDMUD3 nHBxONu71MRP/cod5R66XgTV2nevDVaj11648GxY8h/6jbDPpGcNfYJlnKNlhKYxBE yEPNnwM19OcL9p2wz4fywZ66WM7hPLh1CxZdbEVU= Message-ID: <4F8FC497.3030106@nlnetlabs.nl> Date: Thu, 19 Apr 2012 09:53:59 +0200 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201204181900.VAA29701@TR-Sys.de> In-Reply-To: <201204181900.VAA29701@TR-Sys.de> X-Enigmail-Version: 1.4a1pre X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 19 Apr 2012 09:54:00 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Review of draft-ietf-dnsext-rfc1995bis-ixfr-00.txt (from Knot DNS team) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQpIYXNoOiBTSEExCgpPbiAwNC8xOC8y MDEyIDA5OjAwIFBNLCBBbGZyZWQg77+9IHdyb3RlOgouLi4KPj4gMykgU2VjdGlvbiAyLCBsYXN0 IHBhcmFncmFwaCAtIHdoeSBoYXMgdG8gUlJTSUcoU09BKSBbdG9dIGZvbGxvdyAKPj4gdGhlIFNP QSBpbiB0aGUgQVhGUi1mYWxsYmFjayBleGFtcGxlPwo+IAo+IEFjdHVhbGx5LCB0aGVyZSdzIG5v ICJNVVNUIiByZXF1aXJlbWVudCwgYnV0IGl0IGlzIGdvb2QgcHJhY3RpY2UgaW4KPiBBWEZSIGlt cGxlbWVudGF0aW9ucyB0byBncm91cCBSUnNldHMgdG9nZXRoZXIgaW4gQVhGUiByZXNwb25zZXMs IAo+IGFuZCwgYWNjb3JkaW5nIHRvIHRoZSBiYXNlIEROU1NFQyBzcGVjcywgdGhlIFJSU0lHKFNP QSkKPiBjb25jZXB0aW9uYWxseSBpcyBwYXJ0IG9mIHRoZSBTT0EgUlJzZXQgKGV4Y2VwdCBpbiB0 aGUgY29udGV4dCBvZiBhCj4gcXVlcnkgZm9yIFJSU0lHLCB3aGljaCBkb2VzIG5vdCBhcHBseSBo ZXJlKS4gIEhvd2V2ZXIsIHNlcnZlcgo+IGltcGxlbWVudGF0aW9ucyBoYXZlIGZvdW5kIGl0IGNv bnZlbmllbnQgdG8gc2VuZCBSUnNldHMgYXMKPiBjb250aWd1b3VzIGdyb3VwcyB3aXRoaW4gQVhG UiByZXNwb25zZXMgKGJlY2F1c2Ugb2YgdGhlIG1hbm5lciB0aGV5Cj4gYXJlIHN0b3JlZCwgZm9y IGdyb3VwZWQgaW5jbHVzaW9uIGluIG9yZGluYXJ5IEROUyByZXNwb25zZXMpOwo+IHNpbWlsYXJs eSwgZm9yIGNsaWVudHMgdGhhdCBjaG9vc2UgdG8gcGVyZm9ybSBkZXRhaWxlZCBwbGF1c2liaWxp dHkKPiBjaGVja3Mgb2YgcmVjZWl2ZWQgem9uZSBjb250ZW50IGJlZm9yZSBzZXJ2aW5nIGEgbmV3 IHZlcnNpb24gb2YgdGhlCj4gem9uZSBkYXRhLCBjaGVja2luZyBvZiBjb25zaXN0ZW5jeSBsaWtl bHkgd2lsbCBjb21wcmlzZSBhIGNoZWNrIGZvcgo+IGVxdWFsaXR5IG9mIFRUTCB2YWx1ZXMgd2l0 aGluIFJSc2V0cyAoU2VjdGlvbiA1LjIgb2YgUkZDIDIxODEpLCBhbmQKPiBtYXliZSBldmVuIFJS U0lHIHZlcmlmaWNhdGlvbiwgaXQgaXMgYmVuZWZpY2lhbCB0byByZWNlaXZlIHRoZSBSUnMKPiBv ZiBSUnNldHMgZ3JvdXBlZCB0b2dldGhlciAoc28gdGhhdCBjb21tb24gRFJBTSBjYWNoZSByZXBs YWNlbWVudAo+IGFsZ29yaXRobXMgbWFrZSBpdCBtdWNoIG1vcmUgbGlrZWx5IHRvIGZpbmQgdGhl IHJlbGF0ZWQgUlJzIGluIHRoZQo+IG1vc3QgaGlnaC1zcGVlZCBtZW1lb3J5IGNvbW9uZW50cyBw cmVzZW50IGluIHRoZSBzeXN0ZW0sIGFuZCBoZW5jZQo+IHByb2Nlc3Npbmcgd2lsbCBiZSBtdWNo IGZhc3RlcikuICBTaW5jZSBJWEZSIGlzIGFsbCBhYm91dCBzcGVlZCBhbmQKPiBvcHRpbWl6YXRp b24gb2YgdGhlIHpvbmUgc3luY2hyb25pemF0aW9uIHByb2Nlc3MsIHN1Y2ggc2VydmVyCj4gYmVo YXZpb3IgaXMgdmVyeSBkZXNpcmFibGUgaW4gSVhGUiBpbXBsZW1lbnRhdGlvbnMgYXMgd2VsbC4K PiAKPiBUYWtpbmcgdGhpcyBpbnRvIGFjY291bnQsIEkgaGF2ZSB0ZW50YXRpdmVseSBtb2RpZmll ZCB0aGUgZHJhZnQgCj4gdGV4dCB0byBub3cgc2F5Ogo+IAo+ICJJbiBjb250cmFzdCwgaW4gdGhl IGNhc2Ugb2YgZmFsbGJhY2sgdG8gQVhGUiwgdGhlIElYRlIgcmVzcG9uc2UgCj4gd291bGQgdHlw aWNhbGx5IGNvbnZleSwgaW4gb3JkZXI6IiBeXl5eXl5eXl5eXgo+IAo+IEJ1dCBpZiBpbXBsZW1l bnRlcnMgZG8gc3Ryb25nbHkgcHJlZmVyIHRvIGhhdmUgSVhGUiBjbGllbnRzIGZpbmQgCj4gUlJz ZXRzIGdyb3VwZWQgdG9nZXRoZXIsIG9yIGF0IGxlYWVzdCB0byBoYXZlIHRoZSBSUlNJRyhTT0Ep IFJScyAKPiBhbHdheXMgYmUgcGxhY2VkIGF0IHRoZSBiZWdpbm5pbmcgKGluIHRoZSBjYXNlIG9m IElYRlIgZmFsbGJhY2sgdG8KPiBBWEZSKSwgd2UgY291bGQgbWFrZSB0aGUgUlIgb3JkZXIgc2hv d24gaW4gdGhlIGRyYWZ0IG1hbmRhdG9yeSAKPiAoU0hPVUxEIG9yIE1VU1QpIGZvciBJWEZSIHNl cnZlcnMuCj4gCj4gT3BpbmlvbnMgZnJvbSBvdGhlciBpbXBsZW1lbnRlcnM/CgpPcGVuRE5TU0VD IDEuNC4wYTEgZG9lcyBpbmRlZWQgbm93IHRyYW5zZmVyIHRoZSB6b25lIGluIHRoZSBvcmRlciBz dWNoCnRoYXQgc2lnbmF0dXJlcyBmb2xsb3cgdGhlIGNvcnJlc3BvbmRpbmcgUlJzZXRzIGltbWVk aWF0ZWx5LiBIb3dldmVyLApkdWUgdG8gYSBjaGFuZ2UgaW4gdGhlIHdheSB3ZSBzdG9yZSB0aGUg ZGF0YSBpbiB0aGUgYmFja3VwIGZpbGVzLCB0aGF0Cm1pZ2h0IGNoYW5nZSBpbnRvIGZpcnN0IHNl bmQgYWxsIHRoZSBSUnNldHMsIGZvbGxvd2VkIGJ5IGFsbCBOU0VDKDMpcwphbmQgZmluYWxseSBh bGwgUlJTSUdzLCBiZWNhdXNlIHRoYXQncyB0aGUgb3JkZXIgdGhleSBhcmUgc3RvcmVkLgoKWW91 IGFyZ3VlIHRoYXQgdGhpcyBpcyBkaXNhZHZhbnRhZ2VvdXMgZm9yIHRoZSBJWEZSIGNsaWVudCwg YnV0IHRoYXQKaXMgZGVwZW5kaW5nIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiBJIGd1ZXNzLiBJbiBv dXIgY2FzZSwgaXQgd291bGQgYmUKYmVuZWZpY2lhbCBmb3IgdGhlIElYRlIgc2VydmVyIHRvIGRv IG90aGVyd2lzZS4gU28gYXQgbGVhc3QsIEkgd291bGQKZGlzYWdyZWUgd2l0aCBtYWtpbmcgdGhl IFJSIG9yZGVyIG1vcmUgbWFuZGF0b3J5LgoKQmVzdCByZWdhcmRzLAogIE1hdHRoaWpzCgo+PiA0 KSBTZWN0aW9uIDYuMiAtIG1pc3NpbmcgUkZDMjExOSBsYW5ndWFnZTsgc2hvdWxkcyBhbmQgbWF5 cyBhcmUKPj4gc21hbGwgY2FwcywgaXMgdGhhdCBpbnRlbnRpb25hbD8KPiAKPiBUaGUgc2VydmVy J3MgcHVyZ2luZyBiZWhhdmlvciBpcyBkaWZmaWN1bHQgdG8gdGVzdCBleHRlcm5hbGx5LiBJdAo+ IGlzIHN0cm9uZ2x5IHJlY29tbWVuZGVkIHRvIHVzZSBSRkMgMjExOSB0ZXJtcyBzcGFyaW5nbHkg YW5kIG9ubHkgaW4KPiBjYXNlcyB3aGVyZSB0aGUgYmVoYXZpb3IgaXMgbmVlZGVkIGZvciBpbnRl cm9wZXJhYmlsaXR5IGFuZCBjYW4gYmUKPiB0ZXN0ZWQgYnkgb2JzZXJ2aW5nIGV4dGVybmFsbHkg dmlzaWJsZSBiZWhhdmlvci4KPiAKPiBUaGUgbWFuZGF0b3J5IHJ1bGVzIG9uICJmYWxsYmFjayB0 byBBWEZSIiBJTU8gYXJlIHN1ZmZpY2llbnQgdG8gCj4gZW5zdXJlIGludGVyb3BlcmFiaWxpdHks IGFuZCBJWEZSLU9OTFkgaXMgZGVkaWNhdGVkIHRvIGFkZHJlc3MgCj4gZWZmaWNpZW5jeSBpc3N1 ZXMgdGhhdCBwbGFndWUgZGVwbG95bWVudHMgaW4gc3BlY2lmaWMKPiBjaXJjdW1zdGFuY2VzLCBz byB0aGUgZGV0YWlscyBvZiBJWEZSIHNlcnZlciBwdXJnaW5nIGJlaGF2aW9yIHNlZW0KPiB0byBi ZSBsb2NhbCB0byBpbXBsZW1lbnRhdGlvbnMsIHN1YmplY3QgdG8gaW1wbGVtZW50YXRpb24tc3Bl Y2lmaWMKPiByZXNvdXJjZSBtYW5hZ2VtZW50IHN0cmF0ZWdpZXMgYW5kIHJlc291cmNlIHJlc3Ry aWN0aW9ucywgYW5kIGhlbmNlCj4gb3V0IG9mIHRoZSBiYWlsaXdpY2sgb2YgUkZDIDIxMTkuICAo IDotKSApCj4gCj4gSG93ZXZlciwgaWYgdGhlIFdHIGZlZWxzIHN0cm9uZyBhYm91dCBoYXZpbmcg bW9yZSBkZXRhaWxlZCwgeWV0IAo+IHRlc3RhYmxlLCByZXF1aXJlbWVudHMgcmVnYXJkaW5nIHRo ZSBwdXJnaW5nIGFuZCBjb25kZW5zYXRpb24gCj4gc3RyYXRlZ3kgb2YgSVhGUiBzZXJ2ZXJzIChT ZWN0aW9ucyA2LjIgYW5kIDYuMyBvZiB0aGUgSS1EKSwgdGhlCj4gZHJhZnQgb2YgY291cnNlIGNh biBiZSBtb2RpZmllZCBhY2NvcmRpbmdseS4KPiAKPiAKPj4gCj4+IDUpIEFuZCB0b2RheSBuZXcg cXVlc3Rpb24gaGF2ZSBhcnJpc2VkOiAiV2hhdCBzaG91bGQgSVhGUiBjbGllbnQKPj4gZG8gaWYg aXQgcmVjZWl2ZXMgaW5jb21wbGV0ZSBtdWx0aWNodW5rZWQgSVhGUiByZXNwb25zZT8iIEEpCj4+ IGRpc2NhcmQgd2hvbGUgdHJhbnNmZXIgYW5kIHN0YXJ0IG92ZXI7IEIpIHNhdmUgdXNhYmxlIGNo dW5rcwo+PiAoZS5nLiB1c2UgZGF0YSB0byB1cGRhdGUgem9uZSBmcm9tIHNuX28gdG8gc25fbyt4 LCB3aGVyZSBzbl9vK3ggPAo+PiBzbl9uKQo+IAo+IFNlY3Rpb24gNy4xIGFscmVhZHkgaXMgZXhw bGljaXQgaW4gc2F5aW5nIHRoYXQgYW4gSVhGUiBjbGllbnQKPiAiTUFZIiBmb2xsb3cgc3RyYXRl Z3kgQikuICBJbiBwYXJ0aWN1bGFyLCB0aGUgZHJhZnQgc2F5czoKPiAKPiB8Ny4gIENsaWVudCBC ZWhhdmlvciB8IHwgIFsuLi5dIHwgfDcuMS4gIFpvbmUgSW50ZWdyaXR5IHwgfCAgVGhlCj4gZWxh Ym9yYXRpb25zIG9uIFpvbmUgSW50ZWdyaXR5IGZvciBBWEZSIGluIFNlY3Rpb24gNiBvZiBSRkMg NTkzNiB8Cj4gW1JGQzU5MzZdIGFwcGx5IGluIGEgc2ltaWxhciBmYXNoaW9uIGZvciBJWEZSLiB8 IHwgIEhvd2V2ZXIsIGR1cmluZwo+IHRoZSByZWNlaXB0IG9mIGFuIGluY3JlbWVudGFsIElYRlIg cmVzcG9uc2UsIGFuZCB1cG9uIHwgIHN1Y2Nlc3NmdWwKPiBwcm9jZXNzaW5nIG9mIGFuIFNPQSBS UiB0aGF0IHNlcnZlcyBhcyBhIHNlbnRpbmVsIGZvciB0aGUgfCAgZW5kIG9mCj4gYW55IGNoYW5n ZSBpbmZvcm1hdGlvbiBjaHVuaywgYW4gSVhGUiBjbGllbnQgTUFZIGltbWVkaWF0ZWx5IHwKPiBh cHBseSBhbmQgY29tbWl0IHRvIHN0YWJsZSBzdG9yYWdlIHRoZSBTT0Egc2VyaWFsIG51bWJlciBj aGFuZ2UgfAo+IGRlc2NyaWJlZCBieSB0aGF0IGNodW5rIChhbmQgcHJldmlvdXMgY2h1bmtzLCBp ZiBub3QgYWxyZWFkeQo+IGRvbmUpLiB8ICBUaGlzIG9wZXJhdGlvbiBNVVNUIGV4dGVybmFsbHkg YXBwZWFyIGFzIGFuIGF0b21hcgo+IG9wZXJhdGlvbi4gfCB8ICBbLi4uXQo+IAo+IFBsZWFzZSBy ZXZpc2l0IHRoZSBmdWxsIHRleHQgaW4gU2VjdGlvbiA3LjEgZm9yIHRoZSBkZXRhaWxlZCAKPiBj b25zaWRlcmF0aW9ucyBhbmQgdGVsbCB1cyB3aGV0aGVyIHRoYXQgaXMgc3VmZmljaWVudC4KPiAK Pj4gCj4+IE9uZHJlaiBvbiBiZWhhbGYgb2YgTHVib3MKPj4gCj4+IFAuUy46IE91ciBLbm90IERO UyB0ZWFtIChkaWZmZXJlbnQgcGVvcGxlIHRoYW4gb25lIG9mIHRoZSBhdXRob3JzCj4+IG9mIHRo aXMgZG9jdW1lbnQpIHdpbGwgZG8gYSBmdWxsIHJldmlldyBpbiBXR0xDLgo+IAo+IFRoYW5rcyBp biBhZHZhbmNlIQo+IAo+IEkgaG9wZSB0aGF0IHRoZSBjaGFpcnMgd2lsbCBwcm9jZWVkIHRvIGlz c3VlIFdHTEMgb24gdGhlIHVwY29taW5nIAo+IG5leHQgZHJhZnQgdmVyc2lvbjsgZXhwZXJpZW5j ZSBoYXMgc2hvdyB0aGF0IHRoaXMgaXMgYSBzdHJvbmcgCj4gaW5jZW50aXZlIGZvciB0aGUgV0cg dG8gdGFrZSBhIGNsb3NlciBsb29rIGF0IHRoZSBkb2N1bWVudCBhbmQgCj4gY29tbWVudGluZyBv biBpdC4KPiAKPj4gLi4uIDxzbmlwPiAge29yaWdpbmFsIGRyYWZ0IGFubm91bmNlbWVudH0gIDwv c25pcD4KPiAKPiAKPiBLaW5kIHJlZ2FyZHMsIEFsZnJlZC4KPiAKCi0tLS0tQkVHSU4gUEdQIFNJ R05BVFVSRS0tLS0tClZlcnNpb246IEdudVBHIHYxLjQuMTEgKEdOVS9MaW51eCkKQ29tbWVudDog VXNpbmcgR251UEcgd2l0aCBNb3ppbGxhIC0gaHR0cDovL2VuaWdtYWlsLm1vemRldi5vcmcvCgpp UUVjQkFFQkFnQUdCUUpQajhTV0FBb0pFQTh5VkNQc1FDVzVMWW9JQUs0T2hUMDEwc2k5K2ZCR3pu OFJoNGtkCkdZZzVKUmIrbTJqc3dBL1hmcGt0UnJoV0RXamVhOXhDWGRoNlF2WlJRZUhuL2NQUlEw eHcyWExIZEZYS1U1R1QKekhqWGJvWVdOWlRSbmgxbURKZGtHd0xENW9ZdjBhT1NBVk1FZVRuYXNE bG1nUjZTdDNJcUlJUVNsS1pvZUNTMgp6VGhyZEVSVHByekRqbWpsY21aSlpNYzhoNnBNMnZRN2Nw YTVmOTh3QVRhYkJrd0ZJY3UvOUtaamJBZnBVVmJGCjRSWnUzSFc0V3Y3NVFqaXBYck1odFFWeWFV MmlOV3puQXZmWHM0T09vSVp3c3M3dGN5b0J6K2NDTVVYWXhMS1IKSlpMYzIvbDArbzNDdy9YQkhY aXZGN1h3clV0RXNFTFltVzhTa0xrK3BMUVJEQnYyblVvMGpzQVZXQzhkQ1RFPQo9Yjk0QgotLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KZG5zZXh0IG1haWxpbmcgbGlzdApkbnNleHRAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNleHQK From dnsext-bounces@ietf.org Thu Apr 19 02:58:47 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6FA21F8568; Thu, 19 Apr 2012 02:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334829526; bh=gYimyTX5lX7e6RF3U5A0MvvKF7bKDfs8QmX8im1yyDo=; h=From:Message-Id:To:Date:In-Reply-To:References:Mime-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=PqPbESLVv1ottrL//sdKCX4XkED9WLBRsASwjuW1OT9iSLPm8xMjVb6NiOq/TuoBx qJp8YofJeGes7r0x9BqbHDvXE9S81CDyawc/Jf/2gqQ6/6KKOfYRkuodF7OVJJiyWx UNtWCIE+UXmd81Hgg9THRgPPM/V0rWrRBrvnc20g= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7C21F8568 for ; Thu, 19 Apr 2012 02:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.245 X-Spam-Level: X-Spam-Status: No, score=-98.245 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4QcvCWnyoNt for ; Thu, 19 Apr 2012 02:58:45 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id C978F21F8491 for ; Thu, 19 Apr 2012 02:58:44 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA103539432; Thu, 19 Apr 2012 11:57:12 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA03264; Thu, 19 Apr 2012 11:57:10 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204190957.LAA03264@TR-Sys.de> To: dnsext@ietf.org Date: Thu, 19 Apr 2012 11:57:10 +0200 (MESZ) In-Reply-To: References: <201204182159.XAA00506@TR-Sys.de> X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [dnsext] draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Regarding the final point in my previous posting ... >> ... >> >> Finally, a closely related topic / question: >> >> (5) >> The example of "fallback to AXFR" in the draft (at the very end of >> Section 2) currently suggests that, for efficiency at both the IXFR >> server and the IXFR client, for full zone transfer (fallback to AXFR) >> an IXFR server (typically) sends the zone RRs grouped by RRset. >> >> It has been correctly observed that this ordering does not correspond >> to a requirement contained in the new AXFR specification, RFC 5936. >> >> Should this behavior be recommended/RECOMMENDED in the draft >> for new IXFR server implementations? Based on the feedback received, some implementations do this grouping by RRset, but it looks like implementers would prefer the identical set of RR placement/ordering requirements as in RFC 5936 for AXFR, and not to have recommendations beyond that in the IXFR document. I.e., there will be no ordering requirements for the RRs of a zone beyond the dual (and dual-purpose) placement of SOA RRs (conveying the SOA RR as such and serving as structure tags or 'sentinels' for the response). So the final part of Section 2 in the next version of the rfc1995bis I-D will avoid mention of RRsets. My working copy of the draft now says, including the new explanation at the end: ! In contrast, in the case of fallback to AXFR, the IXFR response would ! convey, in order: ! ! * SOA for sn_n # first instance ! * {other RRs of the zone at sn_n, in arbitrary order} ! * SOA for sn_n # repeated as trailing delimiter ! ! In these examples, for convenience "other RRs ..." is used as a ! shorthand for the more precise words "zero or more other RRs ...". Agreed? Kind regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 19 08:00:01 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E006521F85A4; Thu, 19 Apr 2012 08:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334847601; bh=9pHyuOLKVPDEOHdyZHjaKkTE1GO9xlDuKzSsjs8RVyE=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=pAtnO38OVI2by5Gq4HyHlh12RRLAWgaI7G29rBhPguoJExHvjt83Wq7VyKPHn3qdF Dp+kWKODIXNv36etHayi4B2b0vYOr8VeqQF7fKhoHhQWJowkC/p4M8jNGHUrmfJ6oe MS0aDwbmyCBEW683mo1BleMzwXUpVGAE3vFXskdk= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE42321F84B9; Thu, 19 Apr 2012 07:59:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVMJfR+Tx6Ln; Thu, 19 Apr 2012 07:59:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653F321F84E4; Thu, 19 Apr 2012 07:59:55 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120419145955.17984.92956.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2012 07:59:55 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2672bis-dname-26.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : DNAME Redirection in the DNS Author(s) : Scott Rose Wouter Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-26.txt Pages : 22 Date : 2012-04-19 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision to the original specification in RFC 2672 (which this document obsoletes) as well as updating RFC 3363 and RFC 4294 to align with this revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-26.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-26.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 19 11:04:47 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E419111E8085; Thu, 19 Apr 2012 11:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334858686; bh=78tBw9Buu+P11xepOioLIexbOBo+VKCAxRxkdlZPfCo=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=y3a2dsiMJmlTtcPofbczLwYHZcXTBZu4PDo839fCFfub/eO3cxM6LZlF38weBjOrT ry/V6NvTFh0JgSIZUbl8KMrb9T5joNS8LWl4/zmU7d8vmaruDyNuk5tcTy9VXYkWTM S1PVVcF/tUy94efkZ2UEimrZd3MsU4lWLLR8FJis= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0B221F85C5; Thu, 19 Apr 2012 11:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWFPr007CjXA; Thu, 19 Apr 2012 11:04:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9978B21F85C4; Thu, 19 Apr 2012 11:04:42 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120419180442.6773.85585.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2012 11:04:42 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-update-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-registry-update-02.txt Pages : 6 Date : 2012-04-19 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-02.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 19 11:05:46 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548B221F85FF; Thu, 19 Apr 2012 11:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334858746; bh=RFJs7FtFan6RB3zWecmduiMkuukcdkHMP4WjMAF9Xfo=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=N1diIO+9t15//PYB8FPvDNvYLZiYp5PvAKl0B4rF+v8nWfklrjKbEvRhTNZfSRPqu 4yf0elqSBL6TuE014R0TbX9hFnkFxwL15sN+/V2IFwZEjwJJ0e2aZxEd64YaaBm8KB lIkmsS1+6SQBoryoL342i1a49ziuxoa5MhVu8H6s= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CEF21F8610; Thu, 19 Apr 2012 11:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M-gD8xYA0LT; Thu, 19 Apr 2012 11:05:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721ED21F85EF; Thu, 19 Apr 2012 11:05:40 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120419180540.7094.55392.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2012 11:05:40 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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 : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-imp-status-02.txt Pages : 6 Date : 2012-04-19 The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-02.txt _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Thu Apr 19 11:11:47 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B128621F84BF; Thu, 19 Apr 2012 11:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334859107; bh=jxie74Xslm3CIxfkau36yqrAz4EGpChrFNWkyI0i8K8=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=NuwBrIQtRwxqVFlHu20D67drJVKGRb8kTPZsLQYL8Mn+wleRoj/CweKnb6W6Nufv6 ViciBg6m6H87/q6BiDjjoEzG5/5po0toU4YCfLSOy2gFtZsNxxzlxiEl3GrqBYsdOR qQNjW1aRX8cOMVd++ZnSFd3WAVPjJ/dKBn45/Mm0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B62D21F84DA for ; Thu, 19 Apr 2012 11:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9iHamKP8LoG for ; Thu, 19 Apr 2012 11:11:45 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB6721F84CD for ; Thu, 19 Apr 2012 11:11:45 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q3JIBTQW021389 for ; Thu, 19 Apr 2012 14:11:30 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Scott Rose In-Reply-To: <20120419180442.6773.85585.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2012 14:11:29 -0400 Message-Id: <7D410627-95F7-491F-A590-9613AED5B720@gmail.com> References: <20120419180442.6773.85585.idtracker@ietfa.amsl.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-update-02.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org This draft (and the draft-ietf-dnsext-algo-imp-status-02 update) reflect the comments received in the -01 draft. The only significant change is in the algo-imp-status draft to move ECDSA from Optional to Recommended to Implement (based on WG comments). Scott On Apr 19, 2012, at 2:04 PM, 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 : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates > Author(s) : Scott Rose > Filename : draft-ietf-dnsext-dnssec-registry-update-02.txt > Pages : 6 > Date : 2012-04-19 > > The DNS Security Extensions (DNSSEC) requires the use of > cryptographic algorithm suites for generating digital signatures over > DNS data. The algorithms specified for use with DNSSEC are reflected > in an IANA maintained registry. This document presents a set of > changes for some entries of the registry. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-update-02.txt > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 20 02:00:54 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E200121F8569; Fri, 20 Apr 2012 02:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334912453; bh=CGZ/k3n+tYTrYZbIVt1OnjjxccrC5grtu+65Mv9Nk7o=; h=MIME-Version:Message-ID:Date:To:In-Reply-To:References:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=j7QJQy7uTHb8XcXCss6TIjdwKqvqwvlbgOIhh/gmYnNqMJLA/n7uS9LZOO9ixyhmS 31JQ3wPAuCxhASV9gtWehpQbiPSWF3BfzVcFmg2/d7AMYKAolMZM/8WYVHWDGR/0eD P09HFLQG8gMwRLnLU/7rM4z3BjEyJlPEWPGJeof4= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006821F8569 for ; Fri, 20 Apr 2012 02:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkiC4FWelx8z for ; Fri, 20 Apr 2012 02:00:50 -0700 (PDT) Received: from gunk.araneus.fi (gunk.araneus.fi [166.84.6.82]) by ietfa.amsl.com (Postfix) with ESMTP id 15E5821F84BF for ; Fri, 20 Apr 2012 02:00:49 -0700 (PDT) Received: from guava.gson.org (guava.gson.org [10.0.11.2]) by gunk.araneus.fi (Postfix) with ESMTP id 9BBC71D01B8; Fri, 20 Apr 2012 09:00:46 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 43D2775E62; Fri, 20 Apr 2012 12:00:47 +0300 (EEST) MIME-Version: 1.0 Message-ID: <20369.9662.782882.466650@guava.gson.org> Date: Fri, 20 Apr 2012 12:00:46 +0300 To: Alfred Hoenes In-Reply-To: <201204182159.XAA00506@TR-Sys.de> References: <201204182159.XAA00506@TR-Sys.de> X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Alfred, You wrote: > As already indicated in the draft, there are a few specific > conditions where the interpreation of an IXFR response cannot be > disambiguated until (and if) the next response message arrives, > unless IXFR servers are required to packetize their responses > in a manner that allows immediate disambiguation at the client. > Waiting (in corner cases) for another response message in a given > IXFR session in order to eventually determine the status of the > response requires the IXFR client to set a timeout and wait -- as > a normal protocol operation. All such timeouts are generally > regarded as detrimental, and in particular detrimental to the > performance optimization we have as a target goal for IXFR. Waiting for additional messages to arrive (with a timeout for error recovery) is a standard part of any protocol involving multi-message responses and should not be considered detrimental as such. The detrimental case would be if a client could not determine in advance whether or not the server is going to send another message, and had to resort to using a timeout as a way of detecting the end of the response as part of normal protocol operation. The IXFR protocol as specified in RFC 1995 does *not* require clients to resort to such methods; it is always possible for an RFC 1995 client to unambiguously determine whether or not the server will send an additional message. Digging in the archives, I found a draft from an earlier effort to produce an update to the IXFR specification, back in 2000: http://tools.ietf.org/html/draft-ietf-dnsext-ixfr-01 Quoting that draft: A slave receiving an IXFR response needs to classify it as one of the following four cases: UDP-overflow An indication that the transfer will not fit in a UDP packet and should be retried over TCP up-to-date An indication that the serial number of the request is current and no transfer is necessary incremental An incremental transfer nonincremental A full zone transfer Performing this classification requires some care. For example, UDP-overflow responses differ from UDP up-to-date responses only in the value of the SOA serial number. Also, to distinguish between a nonincremental and an incremental transfer, the slave needs to receive the first two response RRs and check whether the second one is a SOA. If the master chose to transmit each RR in a separate TCP message, this involves waiting for a second TCP response message. On the other hand, in the case of an up-to-date response, the slave must not wait for a second TCP message as doing so would cause it to hang waiting for a message the master will never send. Therefore, the slave must examine the first message and eliminate the possibility that it is a TCP up-to-date response before it attempts to receive a second message. Slaves must not attempt to classify a response based on incidental information such as the presence or absence of a question section, the QTYPE field of a possible question section, or the number of response RRs in a TCP response message. An example algorithm for classifying IXFR responses appears in Appendix A. > Therefore, unless strong consensus to the contrary arises quickly, > the next draft version will contain a more precise description of > what conditions indicate the end of an IXFR response, and how the > different kinds of IXFR responses are to be disambiguated. I suggest doing the latter by reusing the above quoted text from draft-ietf-dnsext-ixfr-01, and/or the pseudocode from its Appendix A. > But this needs to impose on IXFR servers a very few new, specific, > stronger requirements for the packetization of their responses. > These conditions already are in the draft, but the text will be > revised to distinguish the new requirements and spell out the > rationale. I still say there is no actual need to introduce any such new packetization requirements. Regards, -- Andreas Gustafsson, gson@araneus.fi _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Fri Apr 20 03:59:06 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054EB21F8748; Fri, 20 Apr 2012 03:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1334919546; bh=UUYNKJRS9jDys27WHrZhVReED7+fSaci//s4AuCji5w=; h=From:Message-Id:To:Date:In-Reply-To:Mime-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=y7angbLgrg9psSGS5mSQyK9JDLwoqRCGfaIhzN5Uxk1b9KumBNAYfHwCgCC+f82VA Bl4IL07Xp0Qs3TOnHpmd/+hGC6NjMyPBPwCmmtDceNUs1/VEtR3+IMz9apHQvvbe3U 52Pda6cjwpokZ+tgFcQUWuwXpeU9wyzmaV/7RMvA= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667A421F8748 for ; Fri, 20 Apr 2012 03:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.278 X-Spam-Level: X-Spam-Status: No, score=-98.278 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3khFfrpZF6AI for ; Fri, 20 Apr 2012 03:59:03 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3B42821F8747 for ; Fri, 20 Apr 2012 03:59:01 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA109889465; Fri, 20 Apr 2012 12:57:45 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA09367; Fri, 20 Apr 2012 12:57:43 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204201057.MAA09367@TR-Sys.de> To: gson@araneus.fi Date: Fri, 20 Apr 2012 12:57:43 +0200 (MESZ) In-Reply-To: <20369.9662.782882.466650@guava.gson.org> from Andreas Gustafsson at Apr "20, " 2012 "12:00:46" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Andreas, thanks for your additional feedback. > Alfred, > > You wrote: >> As already indicated in the draft, there are a few specific >> conditions where the interpreation of an IXFR response cannot be >> disambiguated until (and if) the next response message arrives, >> unless IXFR servers are required to packetize their responses >> in a manner that allows immediate disambiguation at the client. >> Waiting (in corner cases) for another response message in a given >> IXFR session in order to eventually determine the status of the >> response requires the IXFR client to set a timeout and wait -- as >> a normal protocol operation. All such timeouts are generally >> regarded as detrimental, and in particular detrimental to the >> performance optimization we have as a target goal for IXFR. > > Waiting for additional messages to arrive (with a timeout for error > recovery) is a standard part of any protocol involving multi-message > responses and should not be considered detrimental as such. The > detrimental case would be if a client could not determine in advance > whether or not the server is going to send another message, and had to > resort to using a timeout as a way of detecting the end of the > response as part of normal protocol operation. The IXFR protocol as > specified in RFC 1995 does *not* require clients to resort to such > methods; it is always possible for an RFC 1995 client to unambiguously > determine whether or not the server will send an additional message. But that has not been described in RFC 1995. > Digging in the archives, I found a draft from an earlier effort to > produce an update to the IXFR specification, back in 2000: > > http://tools.ietf.org/html/draft-ietf-dnsext-ixfr-01 > > Quoting that draft: > > A slave receiving an IXFR response needs to classify it as one of the > following four cases: > > UDP-overflow An indication that the transfer will not fit in a > UDP packet and should be retried over TCP > > up-to-date An indication that the serial number of the > request is current and no transfer is necessary > > incremental An incremental transfer > > nonincremental A full zone transfer > > Performing this classification requires some care. For example, > UDP-overflow responses differ from UDP up-to-date responses only in > the value of the SOA serial number. Also, to distinguish between a > nonincremental and an incremental transfer, the slave needs to > receive the first two response RRs and check whether the second one > is a SOA. If the master chose to transmit each RR in a separate TCP > message, this involves waiting for a second TCP response message. On > the other hand, in the case of an up-to-date response, the slave must > not wait for a second TCP message as doing so would cause it to hang > waiting for a message the master will never send. Therefore, the > slave must examine the first message and eliminate the possibility > that it is a TCP up-to-date response before it attempts to receive a > second message. > > Slaves must not attempt to classify a response based on incidental > information such as the presence or absence of a question section, > the QTYPE field of a possible question section, or the number of > response RRs in a TCP response message. > > An example algorithm for classifying IXFR responses appears in > Appendix A. Interesting quote; thanks! I've picked up that draft now. But guess what I already have in my working copy draft-ietf-dnsext-rfc1995bis-ixfr-01(alpha), in Section 4 ... ! The possible IXFR responses can be classified into various kinds of ! responses by the number of answer RRs in the conceptual response. ! ! immediate-error: empty answer, non-zero RCODE; ! ! redirect-to-conn: single SOA RR for sn_n > sn_o, RCODE = NoError; ! ! you-are-current: single SOA RR for sn_n = sn_o, RCODE = NoError; ! ! you-are-more-recent: single SOA RR for sn_n < sn_o, RCODE = NoError; ! ! incremental: multiple RRs, starting and ending with the SOA RR for ! sn_n > sn_o, which enclose a sequence of one or more change ! information chunks, the first of which starts with the SOA RR for ! sn_o (which consequentially is different from sn_n); ! this is detailed below in Section 4.1 ! (if need arises, a packetized incremental response can be aborted ! in the second or later response message by sending an empty Answer ! section and non-zero RCODE); ! ! fallback-to-axfr: multiple RRs, starting and ending with the SOA RR ! for sn_n > sn_o, enclosing a serialization of all other RRs in the ! zone for sn_n (which hence does not contain any other SOA RR and ! consequentially cannot start with another SOA RR); ! this is detailed in [RFC5936] ! (if need arises, a packetized fallback-to-axfr response can be ! aborted in the second or later response message by sending an ! empty Answer section and non-zero RCODE). ... sounds very similar, isn't it? It's consoling that independent analysis now led to comparable results as the thinking was more than a decade ago. :-) >> Therefore, unless strong consensus to the contrary arises quickly, >> the next draft version will contain a more precise description of >> what conditions indicate the end of an IXFR response, and how the >> different kinds of IXFR responses are to be disambiguated. > > I suggest doing the latter by reusing the above quoted text from > draft-ietf-dnsext-ixfr-01, and/or the pseudocode from its Appendix A. Firstly, see above; second, -- excluding the treatment of error cases that our draft also covers -- the only significant difference between that pseudocode and the more detailed description in our I-D (already being expanded upon as well in my working copy) seems to be the requirement for the second RR to be contained in the first response packet to avoid the waiting for the second packet before 'incremental' can be distinguished unambiguously from 'fallback-to-axfr'. Expect our -01 version to be uploaded by early next week (my co-authors were busy on a conference this week). >> But this needs to impose on IXFR servers a very few new, specific, >> stronger requirements for the packetization of their responses. >> These conditions already are in the draft, but the text will be >> revised to distinguish the new requirements and spell out the >> rationale. > > I still say there is no actual need to introduce any such new > packetization requirements. According to feedback from current implementers, they seem to have no trouble with the suggested small tightening -- in particular as it effectively needs no additional effort in server implementations that already follow the "SHOULD" for AXFR in RFC 5936 (to pack as much answer RRs into the response packets as possible) and reuse related code for IXFR. I note that the example in Section 7 of the '2000 draft also shows answer RR packing, which is needed anyway if the IXFR server intends to make use of the option to send (packed) incremental (or even fallback-to-axfr) responses in a single UDP response packet, if they fit therein. Best refards, Alfred. > Regards, > -- > Andreas Gustafsson, gson@araneus.fi Best regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 23 03:07:42 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C549D21F8692; Mon, 23 Apr 2012 03:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335175662; bh=jSNXIN4Wgf4Z6m7Y8ie2r/lpF1Bo1Z0Zk4LqbJsEwyw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=LbUURLe/kfZs86cTa76kYf7uZXcBjHkDzNl7ct6+diyI9I6eBEwH//bbRtuw28Y/x XM3hcS92Ru+7Gg1wDSiOD9GnAVOzIGBWjYMa+4mUOCSRhm8CtZ8J3RBRuwvv0xoLNf QRURRX6BPE76ZDC8M1P38977/MFV3FDUEyTFb8UE= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5621D21F8690 for ; Mon, 23 Apr 2012 03:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4WnwNGbxkpu for ; Mon, 23 Apr 2012 03:07:40 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 72EA521F8682 for ; Mon, 23 Apr 2012 03:07:40 -0700 (PDT) Received: (qmail 97731 invoked from network); 23 Apr 2012 10:43:10 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 23 Apr 2012 10:43:10 -0000 Message-ID: <4F9529C8.2020507@necom830.hpcl.titech.ac.jp> Date: Mon, 23 Apr 2012 19:07:04 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dnsext@ietf.org References: <201204181512.RAA28025@TR-Sys.de> In-Reply-To: <201204181512.RAA28025@TR-Sys.de> Subject: Re: [dnsext] technical errata filed for RFC 1995 (eid=3196/3197) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org KDIwMTIvMDQvMTkgMDoxMiksIEFsZnJlZCDvv70gd3JvdGU6Cgo+IEZvciB0aGUgcmVjb3JkLCBJ IGhhdmUgbm93IGZpbGVkIHR3byBjb3JyZXNwb25kaW5nIFRlY2huaWNhbCBFcnJhdGEKPiBpbmNs dWRpbmcgYSBzaG9ydCAiSGlzdG9yaWNhbCBOb3RlIiBmb3IgY2xhcmlmaWNhdGlvbiBvZiB0aGUK PiBwcmVjZWRlbmNlOyBzZWUKPiAgICBodHRwOi8vd3d3LlJGQy1FZGl0b3IuT1JHL2VycmF0YV9z ZWFyY2gucGhwP3JmYz0xOTk1CgpGb3IgeW91ciBmaXJzdCBwb2ludDoKCiA+ICAgSWYgYW4gSVhG UiBxdWVyeSB3aXRoIHRoZSBzYW1lIG9yIG5ld2VyIHZlcnNpb24gbnVtYmVyIHRoYW4gdGhhdCBv ZgogPiAgIHRoZSBzZXJ2ZXIgaXMgcmVjZWl2ZWQsIGl0IGlzIHJlcGxpZWQgdG8gd2l0aCBhIHNp bmdsZSBTT0EgcmVjb3JkIG9mCiA+ICAgdGhlIHNlcnZlcidzIGN1cnJlbnQgdmVyc2lvbiwganVz dCBhcyBpbiBBWEZSLgoKdGhlIG9yaWdpbmFsIGludGVudGlvbiBpcyAianVzdCBhcyBmb3IgcHJl Y2VkaW5nIFNPQSBxdWVyeSBpbiBBWEZSIAp0cmFuc2FjdGlvbiBleGNoYW5nZXMiLgoKRm9yIHlv dXIgdGhpcmQgcG9pbnQsIHlvdXIgcmVwbGFjZW1lbnQgb2YgIlJScyIgdG8gIlJSc2V0cyIgb25s eQppbmNyZWFzZXMgY29uZnVzaW9uIGJlY2F1c2UgIlJScyIgb2YgUkZDMTk5NSBtZWFucywgYWNj b3JkaW5nCnRvIHlvdXIgdGVybWlub2xvZ3ksICJhbiBSUnNldCIuCgpBcyBSRkMxMDM1IHN0YXRl cyAiYSBwb3NzaWJseSBwYXJ0aWFsIHNldCBvZiBSUnMiLCB0aGUKb3JpZ2luYWwgdGVybWlub2xv Z3kgb2YgIlJScyIgbWVhbiAiYW4gUlIgc2V0IiBzaG91bGQgYmUKcHJlc2VydmVkLgoKID4gU28g dGhlcmUgbmV2ZXIgYXJlIHBhcnRpYWwgUlJzIGluIGFueSBJWEZSIHJlc3BvbnNlIHBhY2tldHMu CgpXaXRoIHRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbiBSRkMxOTk1OgoKICAgICAgIEFuc3dlciAg ICAgfCBKQUlOLkFELkpQLiAgICAgICAgIElOIFNPQSBzZXJpYWw9MyAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgfCBKQUlOLkFELkpQLiAgICAgICAgIElOIFNPQSBzZXJpYWw9MSAg ICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCBORVpVLkpBSU4uQUQuSlAuICAgIElO IEEgICAxMzMuNjkuMTM2LjUgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCBKQUlOLkFE LkpQLiAgICAgICAgIElOIFNPQSBzZXJpYWw9MiAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgfCBKQUlOLUJCLkpBSU4uQUQuSlAuIElOIEEgICAxMzMuNjkuMTM2LjQgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgfCBKQUlOLUJCLkpBSU4uQUQuSlAuIElOIEEgICAxOTIuNDEu MTk3LjIgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCBKQUlOLkFELkpQLiAgICAgICAg IElOIFNPQSBzZXJpYWw9MiAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCBKQUlO LUJCLkpBSU4uQUQuSlAuIElOIEEgICAxMzMuNjkuMTM2LjQgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgfCBKQUlOLkFELkpQLiAgICAgICAgIElOIFNPQSBzZXJpYWw9MyAgICAgICAgICAg ICAgIHwKICAgICAgICAgICAgICAgICAgfCBKQUlOLUJCLkpBSU4uQUQuSlAuIElOIEEgICAxMzMu NjkuMTM2LjMgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCBKQUlOLkFELkpQLiAgICAg ICAgIElOIFNPQSBzZXJpYWw9MyAgICAgICAgICAgICAgIHwKCmEgZnVsbCBSUiBzZXQgaXM6Cgog ICAgICAgSkFJTi1CQi5KQUlOLkFELkpQLiBJTiBBICAgMTMzLjY5LjEzNi4zCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIElOIEEgICAxOTIuNDEuMTk3LjIKCmFuZAoKICAgICAgICAgICAgICAg ICAgfCBORVpVLkpBSU4uQUQuSlAuICAgIElOIEEgICAxMzMuNjkuMTM2LjUgICAgICAgICAgIHwK CmlzIGEgcGFydGlhbCBSUiBzZXQgaW4gdGhlIElYRlIgcmVzcG9uc2UgbWVzc2FnZS4KCiA+IChJ biB0aGUgcGFzdCwgdGhlIElFU0cgaGFzIGFza2VkIGZvciBFcnJhdGEgYXMgYW4gYXJndW1lbnQg dGhhdAogPiBhICdiaXMnIGRvY3VtZW50IGlzIG5lZWRlZDsgc28gSSBob3BlIHRoaXMgbWlnaHQg aGVscCB3aXRoCiA+IGRyYWZ0LWRuc2V4dC1yZmMxOTk1YmlzLWl4ZnIuKQoKSSBzdGlsbCBoYXZl IG5ldmVyIHNlZW4gYW55IHJlYWwgd29ybGQgb3BlcmF0aW9uYWwgcmVhc29uaW5nCmZvciBJWEZS LW9ubHkuCgoJCQkJCQlNYXNhdGFrYSBPaHRhCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5nIGxpc3QKZG5zZXh0QGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Mon Apr 23 11:39:04 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A4221F85CF; Mon, 23 Apr 2012 11:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335206344; bh=/Mg9guvJdtNTyjxo4/uuzzAyvOwnu4O2jMH5M4r/LEs=; h=From:Message-Id:To:Date:Mime-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=J+DOA636ITUJfYNFMZm5T879zzU13G8jS+BLQDd0zXyLofU9hUhXMFO7FKnQZTb/O Fpb+lclEYVK6EWzhdrz4JAv4OuPIZ3hjwkbe6UEXozjdHLnoka1mKH0JuKFepDCSSr 439UB1US0jedb5iCN3RNRMbmLaoURoJ2V59uxn/Q= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B4B21F85CF for ; Mon, 23 Apr 2012 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.008 X-Spam-Level: X-Spam-Status: No, score=-97.008 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS+R402Z-RSF for ; Mon, 23 Apr 2012 11:39:03 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id BBA5421F85C0 for ; Mon, 23 Apr 2012 11:39:02 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA126956265; Mon, 23 Apr 2012 20:37:45 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA01660; Mon, 23 Apr 2012 20:37:43 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204231837.UAA01660@TR-Sys.de> To: d3e3e3@gmail.com Date: Mon, 23 Apr 2012 20:37:43 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: [dnsext] rfc6195bis registration template clarification X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org I tried to figure out whether the rfc1995bis-ixfr draft needs to undergo the RRtype Expert Review per RFC 6195[bis]. It looks like that review only pertains to Data and Meta-RRtypes, (and the draft -- targeting Standards Track -- needs IETF review), but the registration policy table for RRtypes (entry for range 128-255) could be misunderstood to indicate otherwise. When looking at the registration template in RFC 6195[bis], I missed a structured opportunity for the applicant to indicate whether the application is for a Data RR or Meta-RR, which would be significant for IANA to select a proper numerical range in the assignment process. So I suggest to amend clause B. of the template in Appendix A of the rfc6195bis I-D as follows: OLD: | B. Submission Type: | [ ] New RRTYPE | [ ] Modification to existing RRTYPE NEW: | B. Submission Type: | [ ] New RRTYPE | [ ] Modification to existing RRTYPE | | Kind of RRTYPE: | [ ] Data RR | [ ] Meta-RR As an alternative, a new numbered item might be inserted; that would cause the need to renumber the exicsting items, which perhaps is less desirable for backwards compatibility with RFC 6195. A third alternative would be using item numbers "B.1." and "B.2.". Best regards, Alfred. _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Apr 24 03:49:52 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B218721F86AD; Tue, 24 Apr 2012 03:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335264592; bh=d9qOmjAlIoL9CNiNbHqc9VvMgF7ZVojNWsCI9F0iRNQ=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=BWkXgr+jXgk9yhYsIOYf3dKgTrZy81qm55vmsaDsOGhdEfA8ZJ60OU3cOlxighwZc Iw8dnd/Wr6wF9lfDmhRkceRUxy0HNh1t3c8zyCxvp3NdNkjYEwzhUQUEke6s+aa9dz VPpgs/MzkYOoAOfdmlsaMykhVgIylgAc9CFDIjVk= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB5E21F86A5; Tue, 24 Apr 2012 03:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88XDMEolawpp; Tue, 24 Apr 2012 03:49:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA1621F8691; Tue, 24 Apr 2012 03:49:49 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120424104949.6404.559.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 03:49:49 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc1995bis-ixfr-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Incremental Zone Transfer Protocol (IXFR) Author(s) : Alfred Hoenes Ondrej Sury Shane Kerr Filename : draft-ietf-dnsext-rfc1995bis-ixfr-01.txt Pages : 34 Date : 2012-04-24 The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Incremental Zone Transfer (IXFR) is one of the mechanisms and originally was defined in RFC 1995. This document aims to provide a more detailed and up-to-date specification of the IXFR mechanism and to align it with the current specification of the primary zone transfer mechanism, AXFR, given in RFC 5936. Further, based on operational experience, this document juxtaposes to the original IXFR query a new query type, IXFR-ONLY, that will likely be preferred over IXFR in specific deployments. This document obsoletes and replaces RFC 1995. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1995bis-ixfr-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1995bis-ixfr-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc1995bis-ixfr/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Tue Apr 24 04:30:06 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423D521F8722; Tue, 24 Apr 2012 04:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335267006; bh=URggFwVYA0Zh4wgRYEcvwtDPRSIMPBvwAFCMAgTxOe0=; h=From:Message-Id:To:Date:References:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=j//tN2OMSWT9K8keLfF1DtApRQNXUMNdyMm8hLWUGrZIFP34T9DOPn7pOqHVJE3Fp is/mBYFonAaARHmBnN0op+pFx6zKAkVpxAPQ7IQkuArc+zhZNlV6nlzfxd94Y8pMKs FqDflKlWjsPo5rJTZ0ba2XZIJdbqgpeTxPhijjSU= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0D521F8722 for ; Tue, 24 Apr 2012 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.257 X-Spam-Level: X-Spam-Status: No, score=-98.257 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVnrp1vlLc2Z for ; Tue, 24 Apr 2012 04:30:04 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2614B21F8709 for ; Tue, 24 Apr 2012 04:30:02 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA131216907; Tue, 24 Apr 2012 13:28:27 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA06186; Tue, 24 Apr 2012 13:28:26 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201204241128.NAA06186@TR-Sys.de> To: dnsext@ietf.org Date: Tue, 24 Apr 2012 13:28:25 +0200 (MESZ) References: <20120424104949.6404.12352.idtracker@ietfa.amsl.com> X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [dnsext] (fwd) New Version Notification for draft-ietf-dnsext-rfc1995bis-ixfr-01 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="hp-roman8" Content-Transfer-Encoding: base64 Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org SW50ZXJuZXQtRHJhZnRzIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IGp1c3Qgd3JvdGU6Cgo+ IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWRuc2V4dC1yZmMxOTk1YmlzLWl4ZnIt MDEudHh0Cj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbGZyZWQgSG9lbmVz IGFuZCBwb3N0ZWQKPiB0byB0aGUgSUVURiByZXBvc2l0b3J5Lgo+Cj4gRmlsZW5hbWU6ICAgICAg ICBkcmFmdC1pZXRmLWRuc2V4dC1yZmMxOTk1YmlzLWl4ZnIKPiBSZXZpc2lvbjogICAgICAgIDAx Cj4gVGl0bGU6ICAgICAgICAgICBETlMgSW5jcmVtZW50YWwgWm9uZSBUcmFuc2ZlciBQcm90b2Nv bCAoSVhGUikKPiBDcmVhdGlvbiBkYXRlOiAgIDIwMTItMDQtMjMKPiBXRyBJRDogICAgICAgICAg IGRuc2V4dAo+IE51bWJlciBvZiBwYWdlczogMzQKPgo+IEFic3RyYWN0Ogo+ICAgIFRoZSBzdGFu ZGFyZCBtZWFucyB3aXRoaW4gdGhlIERvbWFpbiBOYW1lIFN5c3RlbSBwcm90b2NvbCBmb3IKPiAg ICBtYWludGFpbmluZyBjb2hlcmVuY2UgYW1vbmcgYSB6b25lJiMzOTtzIGF1dGhvcml0YXRpdmUg bmFtZSBzZXJ2ZXJzCj4gICAgY29uc2lzdHMgb2YgdGhyZWUgbWVjaGFuaXNtcy4gIEluY3JlbWVu dGFsIFpvbmUgVHJhbnNmZXIgKElYRlIpIGlzCj4gICAgb25lIG9mIHRoZSBtZWNoYW5pc21zIGFu ZCBvcmlnaW5hbGx5IHdhcyBkZWZpbmVkIGluIFJGQyAxOTk1Lgo+Cj4gICAgVGhpcyBkb2N1bWVu dCBhaW1zIHRvIHByb3ZpZGUgYSBtb3JlIGRldGFpbGVkIGFuZCB1cC10by1kYXRlCj4gICAgc3Bl Y2lmaWNhdGlvbiBvZiB0aGUgSVhGUiBtZWNoYW5pc20gYW5kIHRvIGFsaWduIGl0IHdpdGggdGhl IGN1cnJlbnQKPiAgICBzcGVjaWZpY2F0aW9uIG9mIHRoZSBwcmltYXJ5IHpvbmUgdHJhbnNmZXIg bWVjaGFuaXNtLCBBWEZSLCBnaXZlbiBpbgo+ICAgIFJGQyA1OTM2LiAgRnVydGhlciwgYmFzZWQg b24gb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSwgdGhpcyBkb2N1bWVudAo+ICAgIGp1eHRhcG9zZXMg dG8gdGhlIG9yaWdpbmFsIElYRlIgcXVlcnkgYSBuZXcgcXVlcnkgdHlwZSwgSVhGUi1PTkxZLAo+ ICAgIHRoYXQgd2lsbCBsaWtlbHkgYmUgcHJlZmVycmVkIG92ZXIgSVhGUiBpbiBzcGVjaWZpYyBk ZXBsb3ltZW50cy4KPgo+ICAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIGFuZCByZXBsYWNlcyBS RkMgMTk5NS4KPgo+Cj4gVGhlIElFVEYgU2VjcmV0YXJpYXQKCgpBcyB1c3VhbCwgdGhlIGRyYWZ0 IGFuZCBkaWZmcyAoaW4gdmFyaW91cyBwcmVzZW50YXRpb24gZm9ybXMpCmFzIHdlbGwgYXMgYWRk aXRpb25hbCBpbmZvcm1hdGlvbnMgYXJlIGF2YWlsYWJsZSBhdDoKICBodHRwOi8vdG9vbHMuSUVU Ri5PUkcvaHRtbC9kcmFmdC1pZXRmLWRuc2V4dC1yZmMxOTk1YmlzLWl4ZnItMDEKClRoaXMgZHJh ZnQgdmVyc2lvbiBpcyBhIGRldGFpbGVkIHJldmlzaW9uIG9mIHRoZSBpbml0aWFsIFdHIGRyYWZ0 CnZlcnNpb24gcG9zdGVkIGR1cmluZyBJRVRGIDgzLiAgSXQgY29udGFpbnMgbnVtZXJvdXMgcmVm aW5lbWVudHMKYW5kIGV4cGFuZGVkIHJlYXNvbmluZyBhcyB3ZWxsIGFzIGVkaXRvcmlhbCBmaXhl cyBhbmQgaW1wcm92ZW1lbnRzLgpUaGUgZWRpdHMgcGVyZm9ybWVkIGFyZSBiYXNlZCBvbiBhbiBl dmFsdWF0aW9uIC0tIGJpYXNlZCBieSBXRwpkZWNpc2lvbnMgdGFrZW4gc2luY2UgMjAwMCwgaW4g cGFydGljdWxhciBpbiB0aGUgY29udGV4dCBvZiB0aGUKZGV2ZWxvcG1lbnQgb2YgdGhlIEFYRlIg c3BlY2lmaWNhdGlvbiAoUkZDIDU5MzYpIC0tIG9mIHRoZSBoaXN0b3JpY2FsCm1hdGVyaWFsIHN1 cHBsaWVkIC8gcG9pbnRlZCB0byBieSBBbmRyZWFzIEd1c3RhZnNzb24gYW5kIHJlY2VudCBvbi0K YW5kIG9mZi1saXN0IGNvbW1lbnRzLCBwYXlpbmcgcGFydGljdWxhciBhdHRlbnRpb24gdG8gY29t bWVudHMgZnJvbQphY3RpdmUgY3VycmVudCBpbXBsZW1lbnRlcnMuCgpBcHBlbmRpeCBDLjEgb2Yg dGhlIG5ldyBkcmFmdCB2ZXJzaW9uIGNvbnRhaW5zIGEgZGV0YWlsZWQsIGhpZ2gtbGV2ZWwKbGlz dCBvZiB0aGUgY2hhbmdlcyBzaW5jZSAtMDAuICBGb3IgdGhlIGFjdHVhbCBjaGFuZ2VzLCBwbGVh c2UgcmVmZXIKdG8gdGhlIG9ubGluZSBkaWZmcy4KClBsZWFzZSByZWFkIGFuZCByZXZpZXcgdGhl IGRyYWZ0LgoKR2l2ZW4gdGhhdCB0aGUgbWFqb3IgdGVjaG5pY2FsIHdvcmsgYWxyZWFkeSBoYWQg YmVlbiBkb25lIGluIHRoZQppbmRpdmlkdWFsIGRyYWZ0IHN0YWdlLCB0aGUgYXV0aG9ycyByZWdh cmQgdGhpcyBkcmFmdCB2ZXJzaW9uIG5vdwphcyBjb21wbGV0ZSBhbmQgcmVhZHkgZm9yIFdHTEMs IHNvIHdlIGFzayB0aGUgQ2hhaXJzIHRvIGNvbnNpZGVyCnRoaXMsIHRvIGRyaXZlIHRoZSBXRyB0 byBwcm92aWRlIG1vcmUgZmVlZGJhY2sgYW5kIC0tIGhvcGVmdWxseSAtLQphcHByb3ZhbCB0byBn byBhaGVhZCB3aXRoIHRoZSBkb2N1bWVudCwgYXMgZW52aXNpb25lZCBpbiBQcmFndWUuCgoKS2lu ZCByZWdhcmRzLAogIEFsZnJlZCBIzm5lcy4KCi0tIAoKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKfCBUUi1TeXMg QWxmcmVkIEhvZW5lcyAgIHwgIEFsZnJlZCBIb2VuZXMgICBEaXBsLi1NYXRoLiwgRGlwbC4tUGh5 cy4gIHwKfCBHZXJsaW5nZXIgU3RyYXNzZSAxMiAgIHwgIFBob25lOiAoKzQ5KTcxNTYvOTYzNS0w LCBGYXg6IC0xOCAgICAgICAgIHwKfCBELTcxMjU0ICBEaXR6aW5nZW4gICAgIHwgIEUtTWFpbDog IGFoQFRSLVN5cy5kZSAgICAgICAgICAgICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRuc2V4dCBtYWlsaW5n IGxpc3QKZG5zZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZG5zZXh0Cg== From dnsext-bounces@ietf.org Thu Apr 26 02:31:56 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F6821F87B6; Thu, 26 Apr 2012 02:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335432715; bh=TToRKMnKsCHX3Izlyhdlxvv/jmR1K+JPDh+JoWxVJ/Q=; h=MIME-Version:Message-ID:Date:To:In-Reply-To:References:From:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=pWddKtTwH3eGaU+IQWwxBpPvps5+ETgHz7Clk70LrqSKa/sByw+S538xlTFbgb+SM 0bUYeRiLQvZ8gL4efOjIbbq/Jia0kcUpvbTVfDTreAHzQWGR8O4MNUyok8KG3hESL/ E10A0GnJxe+h9Y9XFZxQ+PP/aJBxLGRHqaCG8mw0= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E8E21F8680 for ; Thu, 26 Apr 2012 02:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyrKWaS3TzeI for ; Thu, 26 Apr 2012 02:31:53 -0700 (PDT) Received: from gunk.araneus.fi (gunk.araneus.fi [166.84.6.82]) by ietfa.amsl.com (Postfix) with ESMTP id B839621F87A5 for ; Thu, 26 Apr 2012 02:31:53 -0700 (PDT) Received: from guava.gson.org (guava.gson.org [10.0.11.2]) by gunk.araneus.fi (Postfix) with ESMTP id B46C71D0E8C; Thu, 26 Apr 2012 09:31:49 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 954CE75E62; Thu, 26 Apr 2012 12:31:50 +0300 (EEST) MIME-Version: 1.0 Message-ID: <20377.5638.38126.16837@guava.gson.org> Date: Thu, 26 Apr 2012 12:31:50 +0300 To: Alfred Hoenes In-Reply-To: <201204201057.MAA09367@TR-Sys.de> References: <20369.9662.782882.466650@guava.gson.org> <201204201057.MAA09367@TR-Sys.de> X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: dnsext@ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org Alfred, Last week, you wrote (referring to the pseudocode in Appendix A of http://tools.ietf.org/html/draft-ietf-dnsext-ixfr-01): > [...] the only significant difference between > that pseudocode and the more detailed description in our I-D (already > being expanded upon as well in my working copy) seems to be the > requirement for the second RR to be contained in the first response > packet to avoid the waiting for the second packet before 'incremental' > can be distinguished unambiguously from 'fallback-to-axfr'. Yes, that difference is the sticking point. > According to feedback from current implementers, they seem to have no > trouble with the suggested small tightening -- in particular as it > effectively needs no additional effort in server implementations > that already follow the "SHOULD" for AXFR in RFC 5936 (to pack as > much answer RRs into the response packets as possible) and reuse > related code for IXFR. As I see it, the proposed requirement to send the first two RRs in the same message isn't so much a "small tightening" as a fundamental change to the nature of the protocol, from one defined in terms of a sequence of RRs where message boundaries carry no meaning to one where the message boundaries are significant. Also, RFC 5936 doesn't actually require packing "as much answer RRs as possible" into the response message. It says: Each AXFR response message SHOULD contain a sufficient number of RRs to reasonably amortize the per-message overhead, up to the largest number that will fit within a DNS message (taking the required content of the other sections into account, as described below). Consider for example a server implementation that chooses to start a new message whenever adding another RR to the current message would cause it to grow larger than 16 kB, in order to take maximum advantage of name compression given that compression pointers can only point into the first 16 kB of the message. I would consider such an implementation compliant with the above SHOULD, but it would not meet the proposed requirement when the second RR in the transfer is larger than 16 kB. Even filling the message with as many answer RRs as possible is not always sufficient meet the proposed requirement. When the second RR is close to 64 kB in size, it may not fit in the same message as the initial SOA even though it would fit in a separate message. If servers will be required to treat this situation as an error instead of just sending the RRs in separate messages, code changes are needed. RFC 5936 also says: Some old AXFR clients expect each response message to contain only a single RR. To interoperate with such clients, the server MAY restrict response messages to a single RR. As there is no standard way to automatically detect such clients, this typically requires manual configuration at the server. There are server implementations where such manual configuration causes single-RR messages to be sent to both AXFR and IXFR clients. A client following the decision procedure in the draft will fail to interoperate with a server configured in this way. > I note that the example in Section 7 of the '2000 draft also shows > answer RR packing, which is needed anyway if the IXFR server intends > to make use of the option to send (packed) incremental (or even > fallback-to-axfr) responses in a single UDP response packet, if > they fit therein. It's not that existing servers are incapable of packing multiple RRs per message, or that they won't do it in the typical case, but that there are atypical cases such as transfers involving large RRs or non-default configurations where the initial SOA can end up being sent in a message of its own. That said, my main objection is not to the draft's "tightening" of what the server may send, but to the corresponding "loosening" of what the client must accept. In other words, whether or not servers are required to send the first two RRs in the same message, clients should be required to accept TCP IXFR responses divided into messages at arbitrary RR boundaries. Regards, -- Andreas Gustafsson, gson@araneus.fi _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 30 10:37:33 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFA521E804B; Mon, 30 Apr 2012 10:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335807453; bh=UJ12ZNFpoXtsBwt1Y0wWD/8qx+QGyxXjAo4Vhf6KYa8=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=NZIDke/4CJptwcUq16osmmPHQxTOtqzDtgBOWaKDHuXrMpMo01FHyAVM+L5gQ6DVK WZeaIA/cChpwRXRO/sM/AEe4pp81mMS7wZQ7zfLUpGvUEdDJcE11LfzuBL4dcIC/tP XIeYMieV5kh5wav3WrtMIJwhJeFGOWD+BPkVZ2uM= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF09B21E804E; Mon, 30 Apr 2012 10:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtMqWtaXngtN; Mon, 30 Apr 2012 10:37:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9021E8047; Mon, 30 Apr 2012 10:37:31 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120430173731.8428.91678.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 10:37:31 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-bis-updates-18.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org 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) : Samuel Weiler David Blacka Filename : draft-ietf-dnsext-dnssec-bis-updates-18.txt Pages : 20 Date : 2012-04-30 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. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-18.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/ _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 30 10:43:46 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8806121F885E; Mon, 30 Apr 2012 10:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335807826; bh=OPwf5C5VVGADKGrJjQ8ySNkNtNa+tArzjBCUb/E/eD4=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=N0JJc9EODESEJicnUK3l0YG5Fo8ECCMK89FStNy/TbrgcTOBnJLP1gMZFIW5CZRTV Dc9SPsC9yh7fyhCVWhpleBkY/vueLi1gLJ+uZqrhyovzT3wqWhXcd0IsTEs9TVPHZW R0Y3l1Fatr170FWIYV29XZpro02g9Pytm/fG5WEI= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B49D21F8872 for ; Mon, 30 Apr 2012 10:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwd8pLMOXgsw for ; Mon, 30 Apr 2012 10:43:44 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0D73421F86FC for ; Mon, 30 Apr 2012 10:43:43 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q3UHhcIP021760; Mon, 30 Apr 2012 13:43:38 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q3UHhbFs021755; Mon, 30 Apr 2012 13:43:38 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 30 Apr 2012 13:43:37 -0400 (EDT) From: Samuel Weiler To: Edward Lewis In-Reply-To: Message-ID: References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 30 Apr 2012 13:43:38 -0400 (EDT) Cc: dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org On Mon, 12 Mar 2012, Samuel Weiler wrote: > On Fri, 20 Jan 2012, Edward Lewis wrote: ... >> 5.9's title is misleading. The content is good, it's about answering from >> cache in the face of a CD query. But "always doing CD" only applies to >> elements that will do their own validation. > > Doesn't it also apply to a non-validating box in the middle? That box may > still need to return +CD data if something downstream wants it. > > The only place I see it not applying is stub resolvers. Rather than alter > the title (since I couldn't think of a good way to do it), I propose adding a > paragraph saying "this doesn't apply to stub resolvers". During his PROTO review, Andrew observed that the CD bit appendix mentions validating stub resolvers and, indeed, it seems to me that section 5.9 would apply to validating stub resolvers also. At least for the moment, I've removed the sentence saying the section doesn't apply to stub resolvers. If there's a better way to fix this, please speak up. -- Sam _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From dnsext-bounces@ietf.org Mon Apr 30 18:27:10 2012 Return-Path: X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA97921E8048; Mon, 30 Apr 2012 18:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335835630; bh=y5YWvvDjn8IFHhP46ihlBP/9cxSsr/GOaDDWrzWHz04=; h=To:From:References:In-reply-to:Date:Message-Id:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: MIME-Version:Content-Type:Content-Transfer-Encoding:Sender; b=PmaKi0tfEbANB6hp+3dX7axO+YaPw4XDDm98CSDXiq/9/+oez2/RcobFUoKd/GiNi K9R/4Sa5s9I3cd8HgQX6pW5SmZvUYc8e6YofcW3kqwL5kTwpqYYPDpkZsDNsT2K+B0 xz1S9H/Tz16JclOLljZfvKcYPPRgtNC3NZD2Y4DA= X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3BC21E8048 for ; Mon, 30 Apr 2012 18:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j85FTSAavHdE for ; Mon, 30 Apr 2012 18:27:08 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2A65B21E8011 for ; Mon, 30 Apr 2012 18:27:08 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E70395F9925; Tue, 1 May 2012 01:26:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4c27:d59:8c27:a78b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 26A06216C31; Tue, 1 May 2012 01:26:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B94E52045DE7; Tue, 1 May 2012 11:26:41 +1000 (EST) To: Samuel Weiler From: Mark Andrews References: <20120120054939.GD4365@mail.yitter.info> <20120120142243.GE4944@mail.yitter.info> In-reply-to: Your message of "Mon, 30 Apr 2012 13:43:37 -0400." Date: Tue, 01 May 2012 11:26:41 +1000 Message-Id: <20120501012641.B94E52045DE7@drugs.dv.isc.org> Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] WGLC: draft-ietf-dnsext-dnssec-bis-updates-16 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dnsext-bounces@ietf.org Errors-To: dnsext-bounces@ietf.org In message , Samuel Weiler writes: > On Mon, 12 Mar 2012, Samuel Weiler wrote: > > > On Fri, 20 Jan 2012, Edward Lewis wrote: > ... > >> 5.9's title is misleading. The content is good, it's about answering from > >> cache in the face of a CD query. But "always doing CD" only applies to > >> elements that will do their own validation. > > > > Doesn't it also apply to a non-validating box in the middle? That box may > > still need to return +CD data if something downstream wants it. > > > > The only place I see it not applying is stub resolvers. Rather than alter > > the title (since I couldn't think of a good way to do it), I propose adding a > > paragraph saying "this doesn't apply to stub resolvers". > > During his PROTO review, Andrew observed that the CD bit appendix > mentions validating stub resolvers and, indeed, it seems to me that > section 5.9 would apply to validating stub resolvers also. At least > for the moment, I've removed the sentence saying the section doesn't > apply to stub resolvers. If there's a better way to fix this, please > speak up. The advice to always set +CD is just *bad*. If you are talking *directly* to the authoritative servers it doesn't hurt. If you are talking through another recursive server it leaves the client unable to get at good data when bad data is being presented to the recursive server. All element of the resolution path SHOULD be validating responses. > -- Sam > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext