From paul.hoffman@vpnc.org Sun Apr 1 18:12:00 2012 Return-Path: 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) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <8CC420BD-C5B6-4444-AC48-A0D127DE7B83@gmail.com> Date: Sun, 1 Apr 2012 18:11:56 -0700 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 02 Apr 2012 01:12:00 -0000 "obsolescing" makes me gag hard enough to call it a problem, not a nit. --Paul Hoffman From paul.hoffman@vpnc.org Sun Apr 1 18:15:57 2012 Return-Path: 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) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 1 Apr 2012 18:15:54 -0700 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 02 Apr 2012 01:15:57 -0000 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. >=20 > 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 From paul.hoffman@vpnc.org Sun Apr 1 18:17:26 2012 Return-Path: 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) Content-Type: text/plain; charset=us-ascii 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 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 02 Apr 2012 01:17:26 -0000 On Mar 26, 2012, at 3:29 PM, RJ Atkinson wrote: > I support the idea of moving ECDSA to "Recommended". +1 --Paul Hoffman From paul.hoffman@vpnc.org Mon Apr 2 05:26:05 2012 Return-Path: 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 02 Apr 2012 12:26:05 -0000 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 From rwfranks@gmail.com Mon Apr 2 06:38:03 2012 Return-Path: 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 Sender: rwfranks@gmail.com 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 Content-Type: multipart/alternative; boundary=20cf3074d2489a222504bcb24c28 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: , X-List-Received-Date: Mon, 02 Apr 2012 13:38:03 -0000 --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-- From ajs@anvilwalrusden.com Mon Apr 2 06:41:48 2012 Return-Path: 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-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Mon, 02 Apr 2012 13:41:48 -0000 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 From scottr.nist@gmail.com Mon Apr 2 06:45:43 2012 Return-Path: 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) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-749949E7-2714-4197-B809-1E071FFEFA63 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: , X-List-Received-Date: Mon, 02 Apr 2012 13:45:43 -0000 --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-- From alex@alex.org.uk Mon Apr 2 07:23:28 2012 Return-Path: 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-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 02 Apr 2012 14:23:28 -0000 --On 2 April 2012 14:37:42 +0100 Dick Franks wrote: >> "obsolescing" makes me gag hard enough to call it a problem, not a nit. > > > Ugly;=C2=A0 but apparently not obsolete, according to my English (EN-GB) > dictionary! > > =C2=A0=C2=A0=C2=A0 obsolesce =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 It is an intransitive verb (see 'intr') above. You cannot obsolesce something. You can, however, make something obselete. Adding a newly specified algorithm to the registry with a - implementation status other than OPTIONAL SHALL entail obsolescing - this document and replacing the table in Section 2.2 (with the new + implementation status other than OPTIONAL SHALL entail making + this document obsolete and replacing the table in Section 2.2 (with the new algorithm entry). Altering the status column value of any existing - algorithm in the registry SHALL entail obsolescing this document and - replacing the table in Section 2.2 above. + algorithm in the registry SHALL entail making this document obsolete = and + replacing the table in Section 2.2 above. Apparently you can "obsolete" something (as used under 'Status of this memo'), so 'obsoleting' would be an alternative, but is almost as horrible IMHO. --=20 Alex Bligh From paul.hoffman@vpnc.org Mon Apr 2 07:46:50 2012 Return-Path: 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) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120402134134.GA22464@mail.yitter.info> Date: Mon, 2 Apr 2012 07:46:46 -0700 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 02 Apr 2012 14:46:50 -0000 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"? >>=20 >=20 > No, and there is no agreement on what list you ought to use either. > STD13 is your best bet. =20 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 From fanf2@hermes.cam.ac.uk Mon Apr 2 09:23:58 2012 Return-Path: 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 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch 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: , X-List-Received-Date: Mon, 02 Apr 2012 16:23:58 -0000 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. From d3e3e3@gmail.com Mon Apr 2 20:10:59 2012 Return-Path: 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Tue, 03 Apr 2012 03:11:00 -0000 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 no= t > 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 th= e > 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 From iesg-secretary@ietf.org Tue Apr 3 04:12:39 2012 Return-Path: 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) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Tue, 03 Apr 2012 11:12:39 -0000 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. From fneves@registro.br Tue Apr 3 07:38:35 2012 Return-Path: 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-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Tue, 03 Apr 2012 14:38:35 -0000 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-- From matthijs@nlnetlabs.nl Wed Apr 4 00:49:03 2012 Return-Path: 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 04 Apr 2012 07:49:03 -0000 -----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----- From Ed.Lewis@neustar.biz Wed Apr 4 08:32:05 2012 Return-Path: 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 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , X-List-Received-Date: Wed, 04 Apr 2012 15:32:05 -0000 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! From d3e3e3@gmail.com Wed Apr 4 09:02:33 2012 Return-Path: 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Wed, 04 Apr 2012 16:02:33 -0000 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 goe= s > 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 From A.Hoenes@TR-Sys.de Wed Apr 4 17:01:03 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 05 Apr 2012 00:01:04 -0000 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 | +------------------------+--------------------------------------------+ From matthijs@nlnetlabs.nl Thu Apr 5 00:41:30 2012 Return-Path: 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Thu, 05 Apr 2012 07:41:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 03/09/2012 08:00 PM, Alfred � wrote: > Folks -- in particular implementers, > > A point has been raised, and for qualified action, the draft authors > need more information and opinions on this part of the draft: > > |3.2. IXFR Response > | > |[...] > | > |3.2.3. Answer Section > | > | The Answer section MUST be populated with the zone change information > | or, in the case of fallback to AXFR, the full zone contents. > | > | 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. > | > | [...] > > Questions: > > a) Does the behavior described in the emphasized sentence make > sense, given the optimisation goals underlying the IXFR design ? I can see why filling up the response as much as possible is more efficient with respect to transport (chance that lesser packets will be needed). To me it makes sense. > b) Do existing implementations follow this direction ? We don't have an IXFR server implementation (yet), but for what its worth: NSD handles this approach for AXFR. OpenDNSSEC will be able to server signed XFRs in version 1.4 and up and it follows this direction for both IXFR and AXFR. > c) Shall we replace the tagged "should" by a "SHOULD", > to make the recommendation even stronger ? I don't have a strong opinion about this, so I am guided by RFC2119 that says use these terms with care and sparingly. My feeling is that lowercase should is fine here. Best regards, Matthijs > > > Kind regards, > Alfred. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfUykAAoJEA8yVCPsQCW5WvQIAKzYSIZmm7AOXEk1t8LwvLuo rIvUPq6s5YfiaTjyiuR247Vb6h5MEcZIB/ErttIFxi3gEqIetAGcV9k840qFH3F2 JvLiptmJlR9veg0YKrL2rmULaJ2pmaii1qWO+LfRsuA37SnTezd/h91SP3MAxHFi L4h4bwluX6dAEDSSXFjyZkOD9/kn/W+nWMvJWqb8Hb90SYQV10IkjpmHoQgQeYdH AL/wULQ0hhTfUcbyw6IesY1YlN+1Oh1hGjBSy5bfM1wU+ViFg27uBOEDMKQOVbqH sQWlXINpwxP4kBpkPB4YilzVdY0JwM1k5ZqknkShCZJhmwNAov8edt5noc4/8n0= =nfGh -----END PGP SIGNATURE----- From mohta@necom830.hpcl.titech.ac.jp Thu Apr 5 01:58:11 2012 Return-Path: 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: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 05 Apr 2012 08:58:12 -0000 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 From drc@virtualized.org Thu Apr 5 09:56:44 2012 Return-Path: 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) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Thu, 5 Apr 2012 09:56:40 -0700 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 05 Apr 2012 16:56:44 -0000 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 From Francis.Dupont@fdupont.fr Fri Apr 6 08:09:44 2012 Return-Path: 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 Sender: Francis.Dupont@fdupont.fr 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: , X-List-Received-Date: Fri, 06 Apr 2012 15:09:44 -0000 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. From paul.hoffman@vpnc.org Fri Apr 6 08:21:11 2012 Return-Path: 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) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201204061509.q36F9g1l017556@givry.fdupont.fr> Date: Fri, 6 Apr 2012 08:20:57 -0700 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 06 Apr 2012 15:21:11 -0000 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 From Francis.Dupont@fdupont.fr Fri Apr 6 11:23:52 2012 Return-Path: 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 Sender: Francis.Dupont@fdupont.fr 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: , X-List-Received-Date: Fri, 06 Apr 2012 18:23:52 -0000 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 From wouter@nlnetlabs.nl Tue Apr 10 06:50:13 2012 Return-Path: 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Tue, 10 Apr 2012 13:50:14 -0000 -----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----- From wjhns1@hardakers.net Tue Apr 10 08:25:03 2012 Return-Path: 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 Content-Type: text/plain 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: , X-List-Received-Date: Tue, 10 Apr 2012 15:25:03 -0000 >>>>> 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. From Francis.Dupont@fdupont.fr Wed Apr 11 03:57:14 2012 Return-Path: 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 Sender: Francis.Dupont@fdupont.fr 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: , X-List-Received-Date: Wed, 11 Apr 2012 10:57:14 -0000 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 From Francis.Dupont@fdupont.fr Wed Apr 11 04:45:10 2012 Return-Path: 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 Sender: Francis.Dupont@fdupont.fr 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: , X-List-Received-Date: Wed, 11 Apr 2012 11:45:11 -0000 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 From wjhns1@hardakers.net Wed Apr 11 09:15:46 2012 Return-Path: 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 Content-Type: text/plain 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: , X-List-Received-Date: Wed, 11 Apr 2012 16:15:46 -0000 >>>>> 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. From mstjohns@comcast.net Wed Apr 11 09:22:37 2012 Return-Path: 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) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Wed, 11 Apr 2012 16:22:37 -0000 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 origi= nal code, by BouncyCastle for its java and C# providers, and Oracle for the E= C code in JDK 1.7. Oh yeah, for NSS from Mozilla. =20 Mike Sent from my iPad On Apr 11, 2012, at 7:45, Francis Dupont wrote: > In your previous mail you wrote: >=20 >> FD> =3D> 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'... >>=20 >> 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. >>=20 >> But the good news is that it's still pretty easy. >=20 > =3D> as far as I can understand from the Fedora mailing-lists, the reason > is patents on EC technology... >=20 > Regards >=20 > Francis.Dupont@fdupont.fr > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From paul.hoffman@vpnc.org Wed Apr 11 20:03:17 2012 Return-Path: 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Thu, 12 Apr 2012 03:03:17 -0000 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 From miekg@atoom.net Thu Apr 12 00:14:25 2012 Return-Path: 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline 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: , X-List-Received-Date: Thu, 12 Apr 2012 07:14:25 -0000 --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-- From Francis.Dupont@fdupont.fr Thu Apr 12 04:17:21 2012 Return-Path: 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 Sender: Francis.Dupont@fdupont.fr 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: , X-List-Received-Date: Thu, 12 Apr 2012 11:17:21 -0000 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). From miekg@atoom.net Thu Apr 12 04:25:14 2012 Return-Path: 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline 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: , X-List-Received-Date: Thu, 12 Apr 2012 11:25:14 -0000 --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-- From ogud@ogud.com Thu Apr 12 06:17:50 2012 Return-Path: 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 12 Apr 2012 13:17:50 -0000 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 From miekg@atoom.net Thu Apr 12 06:45:08 2012 Return-Path: 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline 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: , X-List-Received-Date: Thu, 12 Apr 2012 13:45:08 -0000 --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-- From wwwrun@rfc-editor.org Thu Apr 12 16:49:19 2012 Return-Path: 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: , X-List-Received-Date: Thu, 12 Apr 2012 23:49:19 -0000 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 From Francis.Dupont@fdupont.fr Fri Apr 13 01:55:22 2012 Return-Path: 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 Sender: Francis.Dupont@fdupont.fr 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: , X-List-Received-Date: Fri, 13 Apr 2012 08:55:22 -0000 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 From A.Hoenes@TR-Sys.de Fri Apr 13 08:26:03 2012 Return-Path: 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: , X-List-Received-Date: Fri, 13 Apr 2012 15:26:03 -0000 --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_-- From ajs@anvilwalrusden.com Fri Apr 13 08:30:37 2012 Return-Path: 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-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Fri, 13 Apr 2012 15:30:37 -0000 Colleagues, On Fri, Apr 13, 2012 at 05:24:43PM +0200, Alfred Hönes 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? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Fri Apr 13 08:39:56 2012 Return-Path: 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) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <20120413153000.GB46538@mail.yitter.info> Date: Fri, 13 Apr 2012 08:39:53 -0700 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 13 Apr 2012 15:39:56 -0000 On Apr 13, 2012, at 8:30 AM, Andrew Sullivan wrote: > Colleagues, >=20 > 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. >=20 > 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. =20 >=20 > This once again suggests to me that we need to find a place to publish > this kind of informal material. =20 >=20 > Suggestions? Informational RFCs. --Paul Hoffman From Francis.Dupont@fdupont.fr Fri Apr 13 09:18:02 2012 Return-Path: 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 Sender: Francis.Dupont@fdupont.fr 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: , X-List-Received-Date: Fri, 13 Apr 2012 16:18:02 -0000 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 From sm@resistor.net Fri Apr 13 09:27:58 2012 Return-Path: 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 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , X-List-Received-Date: Fri, 13 Apr 2012 16:27:59 -0000 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 From miekg@atoom.net Fri Apr 13 09:32:39 2012 Return-Path: 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline 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: , X-List-Received-Date: Fri, 13 Apr 2012 16:32:39 -0000 --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-- From wwwrun@rfc-editor.org Fri Apr 13 11:03:20 2012 Return-Path: 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: , X-List-Received-Date: Fri, 13 Apr 2012 18:03:20 -0000 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 From A.Hoenes@TR-Sys.de Fri Apr 13 12:17:57 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 13 Apr 2012 19:17:57 -0000 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. From d3e3e3@gmail.com Mon Apr 16 09:44:50 2012 Return-Path: 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 16 Apr 2012 16:44:50 -0000 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 From ajs@anvilwalrusden.com Mon Apr 16 12:59:37 2012 Return-Path: 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-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Mon, 16 Apr 2012 19:59:37 -0000 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 From paul.hoffman@vpnc.org Mon Apr 16 14:55:55 2012 Return-Path: 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) Content-Type: text/plain; charset=us-ascii 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 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 16 Apr 2012 21:55:55 -0000 > 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 From A.Hoenes@TR-Sys.de Mon Apr 16 15:32:25 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 16 Apr 2012 22:32:25 -0000 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. From ajs@anvilwalrusden.com Mon Apr 16 16:07:56 2012 Return-Path: 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-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Mon, 16 Apr 2012 23:07:56 -0000 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 From ondrej.sury@nic.cz Mon Apr 16 16:17:41 2012 Return-Path: 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= Content-Type: text/plain; charset=utf-8 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 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 16 Apr 2012 23:17:41 -0000 On 16. 4. 2012, at 21:59, Andrew Sullivan wrote: > 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. Yes, please keep the further discussion off this list. And everybody please cool down before responding, or rather do not respond here at = all. Feel free to do whatever you want, but please be aware, that we have not reached the RFC status yet. So same rules applies as when you were using "experimental" allocations in your code. E.g. if you have tools which used TYPE655xx, then feel free to use TYPE52, but clearly mark that as experimental feature, which can change. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From A.Hoenes@TR-Sys.de Wed Apr 18 08:13:50 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 18 Apr 2012 15:13:50 -0000 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. From A.Hoenes@TR-Sys.de Wed Apr 18 12:02:14 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 18 Apr 2012 19:02:15 -0000 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 | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Wed Apr 18 15:00:53 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 18 Apr 2012 22:00:53 -0000 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 | +------------------------+--------------------------------------------+ From matthijs@nlnetlabs.nl Thu Apr 19 00:54:10 2012 Return-Path: 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Thu, 19 Apr 2012 07:54:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/18/2012 09:00 PM, Alfred � wrote: ... >> 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? OpenDNSSEC 1.4.0a1 does indeed now transfer the zone in the order such that signatures follow the corresponding RRsets immediately. However, due to a change in the way we store the data in the backup files, that might change into first send all the RRsets, followed by all NSEC(3)s and finally all RRSIGs, because that's the order they are stored. You argue that this is disadvantageous for the IXFR client, but that is depending on the implementation I guess. In our case, it would be beneficial for the IXFR server to do otherwise. So at least, I would disagree with making the RR order more mandatory. Best regards, Matthijs >> 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. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPj8SWAAoJEA8yVCPsQCW5LYoIAK4OhT010si9+fBGzn8Rh4kd GYg5JRb+m2jswA/XfpktRrhWDWjea9xCXdh6QvZRQeHn/cPRQ0xw2XLHdFXKU5GT zHjXboYWNZTRnh1mDJdkGwLD5oYv0aOSAVMEeTnasDlmgR6St3IqIIQSlKZoeCS2 zThrdERTprzDjmjlcmZJZMc8h6pM2vQ7cpa5f98wATabBkwFIcu/9KZjbAfpUVbF 4RZu3HW4Wv75QjipXrMhtQVyaU2iNWznAvfXs4OOoIZwss7tcyoBz+cCMUXYxLKR JZLc2/l0+o3Cw/XBHXivF7XwrUtEsELYmW8SkLk+pLQRDBv2nUo0jsAVWC8dCTE= =b94B -----END PGP SIGNATURE----- From A.Hoenes@TR-Sys.de Thu Apr 19 02:58:46 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 19 Apr 2012 09:58:46 -0000 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. From internet-drafts@ietf.org Thu Apr 19 07:59:59 2012 Return-Path: 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Thu, 19 Apr 2012 15:00:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. 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.t= xt 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 From internet-drafts@ietf.org Thu Apr 19 11:04:43 2012 Return-Path: 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Thu, 19 Apr 2012 18:04:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Upd= ates 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-updat= e-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 From internet-drafts@ietf.org Thu Apr 19 11:05:43 2012 Return-Path: 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Thu, 19 Apr 2012 18:05:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Applicability Statement: DNS Security (DNSSEC) DNSKEY Al= gorithm 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-statu= s-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 From scottr.nist@gmail.com Thu Apr 19 11:11:46 2012 Return-Path: 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 Content-Type: text/plain; charset=us-ascii 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 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Thu, 19 Apr 2012 18:11:46 -0000 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: >=20 > 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. >=20 > 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 >=20 > 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. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-upda= te-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-updat= e-02.txt >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From gson@araneus.fi Fri Apr 20 02:00:51 2012 Return-Path: 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 20 Apr 2012 09:00:51 -0000 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 From A.Hoenes@TR-Sys.de Fri Apr 20 03:59:04 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 20 Apr 2012 10:59:04 -0000 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. From mohta@necom830.hpcl.titech.ac.jp Mon Apr 23 03:07:41 2012 Return-Path: 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> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Mon, 23 Apr 2012 10:07:41 -0000 (2012/04/19 0:12), Alfred � wrote: > 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 For your first point: > If an IXFR query with the same or newer version number than that of > the server is received, it is replied to with a single SOA record of > the server's current version, just as in AXFR. the original intention is "just as for preceding SOA query in AXFR transaction exchanges". For your third point, your replacement of "RRs" to "RRsets" only increases confusion because "RRs" of RFC1995 means, according to your terminology, "an RRset". As RFC1035 states "a possibly partial set of RRs", the original terminology of "RRs" mean "an RR set" should be preserved. > So there never are partial RRs in any IXFR response packets. With the following example in RFC1995: Answer | JAIN.AD.JP. IN SOA serial=3 | | JAIN.AD.JP. IN SOA serial=1 | | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | | JAIN.AD.JP. IN SOA serial=2 | | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | | JAIN.AD.JP. IN SOA serial=2 | | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | | JAIN.AD.JP. IN SOA serial=3 | | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | | JAIN.AD.JP. IN SOA serial=3 | a full RR set is: JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 IN A 192.41.197.2 and | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | is a partial RR set in the IXFR response message. > (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.) I still have never seen any real world operational reasoning for IXFR-only. Masataka Ohta From A.Hoenes@TR-Sys.de Mon Apr 23 11:39:04 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 23 Apr 2012 18:39:04 -0000 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. From internet-drafts@ietf.org Tue Apr 24 03:49:49 2012 Return-Path: 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Tue, 24 Apr 2012 10:49:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. 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/ From A.Hoenes@TR-Sys.de Tue Apr 24 04:30:04 2012 Return-Path: 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 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit 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: , X-List-Received-Date: Tue, 24 Apr 2012 11:30:04 -0000 Internet-Drafts just wrote: > A new version of I-D, draft-ietf-dnsext-rfc1995bis-ixfr-01.txt > has been successfully submitted by Alfred Hoenes and posted > to the IETF repository. > > Filename: draft-ietf-dnsext-rfc1995bis-ixfr > Revision: 01 > Title: DNS Incremental Zone Transfer Protocol (IXFR) > Creation date: 2012-04-23 > WG ID: dnsext > Number of pages: 34 > > Abstract: > 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. > > > The IETF Secretariat As usual, the draft and diffs (in various presentation forms) as well as additional informations are available at: http://tools.IETF.ORG/html/draft-ietf-dnsext-rfc1995bis-ixfr-01 This draft version is a detailed revision of the initial WG draft version posted during IETF 83. It contains numerous refinements and expanded reasoning as well as editorial fixes and improvements. The edits performed are based on an evaluation -- biased by WG decisions taken since 2000, in particular in the context of the development of the AXFR specification (RFC 5936) -- of the historical material supplied / pointed to by Andreas Gustafsson and recent on- and off-list comments, paying particular attention to comments from active current implementers. Appendix C.1 of the new draft version contains a detailed, high-level list of the changes since -00. For the actual changes, please refer to the online diffs. Please read and review the draft. Given that the major technical work already had been done in the individual draft stage, the authors regard this draft version now as complete and ready for WGLC, so we ask the Chairs to consider this, to drive the WG to provide more feedback and -- hopefully -- approval to go ahead with the document, as envisioned in Prague. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From gson@araneus.fi Thu Apr 26 02:31:54 2012 Return-Path: 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Thu, 26 Apr 2012 09:31:54 -0000 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 From internet-drafts@ietf.org Mon Apr 30 10:37:31 2012 Return-Path: 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Mon, 30 Apr 2012 17:37:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. 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/ From weiler@watson.org Mon Apr 30 10:43:44 2012 Return-Path: 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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , X-List-Received-Date: Mon, 30 Apr 2012 17:43:44 -0000 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 From marka@isc.org Mon Apr 30 18:27:08 2012 Return-Path: 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: , X-List-Received-Date: Tue, 01 May 2012 01:27:08 -0000 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