From jabley@hopcount.ca Wed Apr 3 07:11:24 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCF821F8E96 for ; Wed, 3 Apr 2013 07:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 9-Y8YBNPmhQX for ; Wed, 3 Apr 2013 07:11:22 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id A40FE21F8C14 for ; Wed, 3 Apr 2013 07:11:22 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id mc17so874203pbc.0 for ; Wed, 03 Apr 2013 07:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=AvwbI/eUYGiCUtI/GAw7NLEU6iat1NbaRYHSy5z+/eQ=; b=Dq35BTu5bWaXUSNlrgoGbRPUSA41Lkhu+ppGa8CTg9mxVEujZFd+YxImNcMtK8idKC 4tf8rD66BRb/Qr4AN7jXNVH6I1ofyKgVvvr2YD7z3K//9fAOYD892K0vJS16XEe/1VEg B/Z9VvH4UKpTonB5fJHwFzqfjHoQlVa5Eq51c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer:x-gm-message-state; bh=AvwbI/eUYGiCUtI/GAw7NLEU6iat1NbaRYHSy5z+/eQ=; b=fLyuSBjYrca4/3KMimiL+a8kX6ZwZNHXv7GtwVg5/l2s7Tq+LZCsY1H1+56lMopW7D uKsl3CmKQRKiz6HzStXXn0Zly0hVx+dq60sO4O7gqVUnzQraODoxyeg0I6hfjAp0GiK8 MK+W86Jp4ESjdMYsdMgG6zEWoJb9pkQb7vJv3zx1M0/cVMolka/kKw+nj8W7RZTtLUGW GhzpzrNftzgbICemeiNJaTaPrY5JIhz9vfmKKhrkQk5eVu9EctZKpJzxL0yT0VJp1xwE 7/MLIHRZ2mZGUyYoVWS6YjQU25k/B29zrlcKs6UnQZ7gTgBzmu4iAnJtDMqcTFs6F1lP JIXg== X-Received: by 10.68.189.137 with SMTP id gi9mr2753749pbc.118.1364998282400; Wed, 03 Apr 2013 07:11:22 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:b4dc:867a:70a7:2b9a? ([2001:4900:1042:100:b4dc:867a:70a7:2b9a]) by mx.google.com with ESMTPS id qe3sm6204238pbb.0.2013.04.03.07.11.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 07:11:21 -0700 (PDT) From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> Date: Wed, 3 Apr 2013 10:11:10 -0400 To: "dnsop@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlZrWgV2uEVcM9t3OZR1f0NL68uSGyTatRas7toz3kLmRPKo28ceh1h75J3PsGbqTIo/yje Subject: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:11:24 -0000 Hi all, As advised a month or so ago, the following public comment period is = open: = http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13= -en.htm We have received a small number of responses which are accessible from = that page. The topic at hand and the specific questions that have been asked as = part of the consultation are important ones; the decisions taken will = have operational consequences to any user of the Internet who validates = DNS responses with DNSSEC. If you have experience, opinions or expertise to contribute, it would be = greatly appreciated. The window for being able to submit comments closes = on 12 April 2013 at 23:59 UTC. Many thanks, Joe From paul.hoffman@vpnc.org Wed Apr 3 08:00:54 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CA321F8E58 for ; Wed, 3 Apr 2013 08:00:54 -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 yAkRUCC30f09 for ; Wed, 3 Apr 2013 08:00:53 -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 E86C221F8DA6 for ; Wed, 3 Apr 2013 08:00:52 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r33F0mq8043380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Apr 2013 08:00:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> Date: Wed, 3 Apr 2013 08:00:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:00:54 -0000 On Apr 3, 2013, at 7:11 AM, Joe Abley wrote: > We have received a small number of responses which are accessible from = that page. Maybe that should be a strong indication of how little people care about = this? Note that none of the responses so far come from administrators of = signed TLDs, the folks most directly affected by a roll. It is hard to = tell why that might be, but I suspect that it involves trepidation and = maybe outright fear. Of course, they cannot voice that publicly. > If you have experience, opinions or expertise to contribute, The first and third are way more important that the second, although = people with the second can certainly make it sound like they have the = third. --Paul Hoffman= From jabley@hopcount.ca Wed Apr 3 08:03:52 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB74F21F8A66 for ; Wed, 3 Apr 2013 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 P0UHr4ytnDyH for ; Wed, 3 Apr 2013 08:03:52 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0152621F85F3 for ; Wed, 3 Apr 2013 08:03:51 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id mc8so897256pbc.11 for ; Wed, 03 Apr 2013 08:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=WKc770oKsJnW4aW3PWe2qAoQxd/k78Jvf7T7J//ZcF0=; b=OI3IWxUdZwVmz3+YuzuHTmyM7h/N5rwsINhTcP2Wn9nX+lXL1s5A9AXyoBAwD1LLT1 aurhGROdlkm9j5USE7BGQPz9tZv6Fnjl5yI/mdQ07JnIkhVERUyBUMjNw+aJfcbPi/2A BnpEEn7DHhoEcK0HRFDcADBibfLrLPXBSel64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=WKc770oKsJnW4aW3PWe2qAoQxd/k78Jvf7T7J//ZcF0=; b=REmJ1O/50G2ZEZ+fvK3nddhWiFsLT3u2HEIr0pgIxUdRqehTsIe5jGfqzmvTyzfP7B YvIXQ0qSmJ9S7I1es8wJdcXg/T2WV/0r12CBXsI+5DdBO4LUAOlWzeeraJXmlgQ1hNT6 Oo0yB3oe7L14CZWg/6PfqUDxidAhCshQLHTeR0gBC3VLfb4lR8uwXzGQMKkx3NWuRl6d Wv+BUcXV3/igU3wra33QfCpihuEHzWeKZBWNiakrUiL6feL9oXKhBEuGc5Winjkb5MH+ 7Svn3SfHAJRtObHwQU1dyYRaOql6ouJIu4BhqnS6kznZu4Xb1SkWF4g4z5xwqlmt95+a UdQA== X-Received: by 10.68.41.197 with SMTP id h5mr3046448pbl.88.1365001431593; Wed, 03 Apr 2013 08:03:51 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:b4dc:867a:70a7:2b9a? ([2001:4900:1042:100:b4dc:867a:70a7:2b9a]) by mx.google.com with ESMTPS id u9sm7253048paf.22.2013.04.03.08.03.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 08:03:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> Date: Wed, 3 Apr 2013 11:03:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlKwVf+raGNKZTA0PtPONhAu1GarP80JrIRrZ4fekpPdGmZE46pwaQQ9/pSrX+EIGnHyy6d Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:03:53 -0000 On 2013-04-03, at 11:00, Paul Hoffman wrote: > On Apr 3, 2013, at 7:11 AM, Joe Abley wrote: >=20 >> We have received a small number of responses which are accessible = from that page. >=20 > Maybe that should be a strong indication of how little people care = about this? Maybe, for sure. But in case it's because people just forgot the = question had been asked, I thought I'd send a reminder. > Note that none of the responses so far come from administrators of = signed TLDs, the folks most directly affected by a roll. It is hard to = tell why that might be, but I suspect that it involves trepidation and = maybe outright fear. Of course, they cannot voice that publicly. I think there's an argument that the people most directly affected by a = roll will be end users to whom DNS responses are being validated. A KSK = rollover in the root zone has no impact on signing operations at TLDs, = or at any other zone. >> If you have experience, opinions or expertise to contribute, >=20 > The first and third are way more important that the second, although = people with the second can certainly make it sound like they have the = third. People with experience or expertise usually have opinions, in my = experience :-) Joe= From paul@nohats.ca Wed Apr 3 08:12:03 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79C121F8EAF for ; Wed, 3 Apr 2013 08:12:02 -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 fRP-pOZXW-Ck for ; Wed, 3 Apr 2013 08:12:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0A21F8EAA for ; Wed, 3 Apr 2013 08:12:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZgrNs3sCpz5TB; Wed, 3 Apr 2013 11:11:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OuRCYgFzgsYE; Wed, 3 Apr 2013 11:11:56 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 3 Apr 2013 11:11:56 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 6DF7380BCA; Wed, 3 Apr 2013 11:11:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5FE8180442; Wed, 3 Apr 2013 11:11:55 -0400 (EDT) Date: Wed, 3 Apr 2013 11:11:55 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> Message-ID: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsop@ietf.org WG" , Joe Abley Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:12:03 -0000 On Wed, 3 Apr 2013, Paul Hoffman wrote: >> We have received a small number of responses which are accessible from that page. > > Maybe that should be a strong indication of how little people care about this? Note that none of the responses so far come from administrators of signed TLDs, the folks most directly affected by a roll. Those are not at all most directly affected. The TLDs dont have to do anything. It's the vendors of equipment supporting DNSSEC that have the real issues. If they shipped with a root anchor, and their stuff is offline for 5 years and turned on, their DNS will be broken and 5011 isn't going to be useful to them..... I'd say addressing that problem should be done before rolling the root key. Paul From jabley@hopcount.ca Wed Apr 3 08:14:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303A221F8E6D for ; Wed, 3 Apr 2013 08:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 88MR3v35PRKt for ; Wed, 3 Apr 2013 08:14:31 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0021F8EA7 for ; Wed, 3 Apr 2013 08:14:31 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id y10so891030pdj.40 for ; Wed, 03 Apr 2013 08:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=KMKzWgwJjjGxi/qfdot0zYH9TTI1t0llAw9I5saPmYc=; b=H7DSJRsHGPowVR0AH68TBgJOoAhrOJ78ELbj4AgMp/p7BHQH+YDWeU6KhlbzNJZy5y 4khnOaYqw3UhpeRQw1CsbabDYmfLkIJEj2s5I2pBqis4ET6erq+dnHhYsxcllDvGHIIq vctVpVlgJyQr9vqEPL8vy7TEJFONV9ctzSohE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=KMKzWgwJjjGxi/qfdot0zYH9TTI1t0llAw9I5saPmYc=; b=d7jygQQg20qup3EvYseUiMUC6JFChAd6kAyckZ//a8kEXBJZQ0rzL2omDTyKkxnKo7 rskMrrPs46PkI7Xcp0xfgCq+lceceZyX/YIcYK1jJMrH1ezpK/cCTJpR8/ojHsEH6UPc qmdQw3KlnkJTcRMj5ewPJZy1VYeRoHHriZ36c5O45g9U5J0x8MCNwLT+na+aEydlIh8A UNNToZV0fQs0MvrCBZsys00YzqHO/uuY0bmQfhCH6iPzm0duBffMmRer80Xij6Xc6aM2 OeFV6F1cK/bPfJR8W15ZaU+I2j+IQUqIL80HSxaQo/0idA6VrxzvExheUO880mpF5vrj RDQg== X-Received: by 10.68.216.106 with SMTP id op10mr2983318pbc.171.1365002071206; Wed, 03 Apr 2013 08:14:31 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:b4dc:867a:70a7:2b9a? ([2001:4900:1042:100:b4dc:867a:70a7:2b9a]) by mx.google.com with ESMTPS id qb10sm6315883pbb.43.2013.04.03.08.14.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 08:14:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Wed, 3 Apr 2013 11:14:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A41D9B1-DAD8-4A3F-9B1F-2B0B6918BABF@hopcount.ca> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkJKGF4fkN5GNp/xKXTMoGY69Pcamr7U/oDujWLBwXKXa3kTy4X/x7V1/jLT+Jjl8p30b86 Cc: "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:14:32 -0000 On 2013-04-03, at 11:11, Paul Wouters wrote: > I'd say addressing that problem should be done before rolling the root > key. It would be great to hear such opinions expressed as part of the public = comment process, so that they can be used to identify the approach that = will be followed. Joe= From paul.hoffman@vpnc.org Wed Apr 3 08:15:42 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8D21F8ED3 for ; Wed, 3 Apr 2013 08:15:42 -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 QYEBPoe0zDgr for ; Wed, 3 Apr 2013 08:15:42 -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 58BE621F8AE7 for ; Wed, 3 Apr 2013 08:15:42 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r33FFdNq044163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Apr 2013 08:15:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Wed, 3 Apr 2013 08:15:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <044EBE01-8690-412C-9562-F0D220DA022A@vpnc.org> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:15:42 -0000 On Apr 3, 2013, at 8:03 AM, Joe Abley wrote: >> Note that none of the responses so far come from administrators of = signed TLDs, the folks most directly affected by a roll. It is hard to = tell why that might be, but I suspect that it involves trepidation and = maybe outright fear. Of course, they cannot voice that publicly. >=20 > I think there's an argument that the people most directly affected by = a roll will be end users to whom DNS responses are being validated. There is such an argument, and there is a counter-argument. If rolling = the root key causes visible problems (which I think most of us expect), = it will be followed by lots of press articles that say "see, DNSSEC = isn't reliable". The diminishing of trust has a greater effect on those = who have committed resources to making their zone trustable than to = relying parties. > A KSK rollover in the root zone has no impact on signing operations at = TLDs, or at any other zone. Fully agree. If you focus just on the operations effects, it is easy to = say that there will only be good coming from the roll. I prefer to look = at the effect on the whole system, including the trust that the system = is worthwhile. --Paul Hoffman (who probably should have sent this and the earlier reply = to dnssec-deploy, not dnsop, given that they were about trust and not = operations)= From bortzmeyer@nic.fr Wed Apr 3 08:18:40 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA8021F8BF8 for ; Wed, 3 Apr 2013 08:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 n9ES5h6lJVMF for ; Wed, 3 Apr 2013 08:18:40 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5B421F8BC4 for ; Wed, 3 Apr 2013 08:18:40 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 14BCC280795; Wed, 3 Apr 2013 17:18:06 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 0FE13280530; Wed, 3 Apr 2013 17:18:06 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id 0476E4C0082; Wed, 3 Apr 2013 17:17:36 +0200 (CEST) Date: Wed, 3 Apr 2013 17:17:35 +0200 From: Stephane Bortzmeyer To: Paul Hoffman Message-ID: <20130403151735.GA20820@nic.fr> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dnsop@ietf.org WG" , Joe Abley Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:18:40 -0000 On Wed, Apr 03, 2013 at 08:00:48AM -0700, Paul Hoffman wrote a message of 15 lines which said: > Note that none of the responses so far come from administrators of > signed TLDs, OK, signed TLD employee hat on. > the folks most directly affected by a roll. IMHO, no, the people most affected will be the manager of the validating resolvers (and, by extension, of their users). Many have no easy way to change the root key, or even knowledge they may have to do so (don't shout "5011". Was RFC 5011 actually tested in a real rollover with the current resolvers?) From bortzmeyer@nic.fr Wed Apr 3 08:21:59 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D0D21F8F35 for ; Wed, 3 Apr 2013 08:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 sGVzBuQR+VX8 for ; Wed, 3 Apr 2013 08:21:58 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA8D21F8F2A for ; Wed, 3 Apr 2013 08:21:58 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id DD8E7280795; Wed, 3 Apr 2013 17:21:24 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id D7D92280746; Wed, 3 Apr 2013 17:21:24 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id CBF284C007E; Wed, 3 Apr 2013 17:20:54 +0200 (CEST) Date: Wed, 3 Apr 2013 17:20:54 +0200 From: Stephane Bortzmeyer To: Joe Abley Message-ID: <20130403152054.GA21244@nic.fr> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <1A41D9B1-DAD8-4A3F-9B1F-2B0B6918BABF@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A41D9B1-DAD8-4A3F-9B1F-2B0B6918BABF@hopcount.ca> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dnsop@ietf.org WG" , Paul Wouters , Paul Hoffman Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:21:59 -0000 On Wed, Apr 03, 2013 at 11:14:24AM -0400, Joe Abley wrote a message of 14 lines which said: > It would be great to hear such opinions expressed as part of the > public comment process, Is there a way in this process to say "me too"? (A Like button, may be :-) Because I fully agree with David Burns and do not see the need to write a long message to just say "+1" From each@isc.org Wed Apr 3 09:38:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDEB21F8D41 for ; Wed, 3 Apr 2013 09:38:43 -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 8Vls5nT2ECfs for ; Wed, 3 Apr 2013 09:38:42 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6E721F8A74 for ; Wed, 3 Apr 2013 09:38:42 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9C99AC9424; Wed, 3 Apr 2013 16:38:26 +0000 (UTC) (envelope-from each@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1365007111; bh=5VXaYVyKhRwctGhZ2pT4WVsMCV5gsvachboHby8FIPE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=B2OT/A60Nfn4gUPVPCSRsEse3NnoL+VBOiMkLeZSGb/UVxGl1MvXPJn0Adv7wBTR2 SN87pW9yYstCYFxWpzCMA7xJR2mnJJZiV48lghJpRKiO1BLQdyncH4PJZ6xPzgDn22 m4behU6ezi3pTvKQsueSOsaHgScczDxrcpCc6E/I= 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.pao1.isc.org (Postfix) with ESMTPS; Wed, 3 Apr 2013 16:38:26 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 914A3216C4B; Wed, 3 Apr 2013 16:38:26 +0000 (UTC) Date: Wed, 3 Apr 2013 16:38:26 +0000 From: Evan Hunt To: Stephane Bortzmeyer Message-ID: <20130403163826.GA46759@isc.org> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130403151735.GA20820@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130403151735.GA20820@nic.fr> User-Agent: Mutt/1.4.2.3i X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsop@ietf.org WG" , Paul Hoffman , Joe Abley Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:38:43 -0000 On Wed, Apr 03, 2013 at 05:17:35PM +0200, Stephane Bortzmeyer wrote: > Was RFC 5011 actually tested in a real rollover with the current > resolvers?) Depends what you mean by "real". The BIND implementation has been tested with real keys, but obviously it's never been confronted with an actual real-world root-zone rollover. In principle there's no difference, but in practice I'm less confident: Rolling the root zone means exercising the RFC 5011 code in *many* validating resolvers, on different platforms with different configurations, and with high stakes in the event of failure. The possibility that we've overlooked a test scenario and some validators out there will fail to roll to the new trust anchor correctly is going to give me jitters until we've done it the first time. Then there's the issue Paul mentioned -- gear configured with a root KSK that gets switched off and not rebooted for a few months or years, and then no longer works and can't recover. Unfortunately, none of these concerns get smaller if we wait longer. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From jabley@hopcount.ca Wed Apr 3 09:40:47 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF3621F8F53 for ; Wed, 3 Apr 2013 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 itx98--2kyUW for ; Wed, 3 Apr 2013 09:40:46 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA7521F8BF2 for ; Wed, 3 Apr 2013 09:40:46 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lb1so981038pab.33 for ; Wed, 03 Apr 2013 09:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=4yKOUQ2N4+89ppVxw7w2lwkMb1rxyZWoNlg9X+89uKA=; b=R/7ZuvawZYC/vWrfUHhqYMsNhEsUtQ4j9PFkU2/KOx9Quh37sQopgjtBOLGYgZBLF9 RqyJh/q6GXdKHTjWSD9v22ANZsuZ/d3FXqjUiYPjK/e80c/9nWYKaahVGPVAoPjruA51 48XADLw3yvrVicmP/o+H1RUVenngcdfhh9tmw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4yKOUQ2N4+89ppVxw7w2lwkMb1rxyZWoNlg9X+89uKA=; b=ePy//he3l3G3KvEDuWh+XDvbw3wyc3JmZBWV99mjk1HIK6k0xdWqWgl5e109t2ATkZ tXP0YmKf0/wkDwrqgPGS55AYBn4vY5vzfxxW20faAeuIXoiPDzBkOrO5O017nX20/Ftv cknXkBME3a2E7x83++8YFU6VK57C25iZG45ELnoGHb3tKIAB+valCghME1llP8hBi8Zr CJbpoZQY6BeJnrgWJ1Ad5zL1xhS+oS0BWNjOq5u3msK/9r5JPUmIcmMr+npjfz+Nb4fI WNSg5JHWsbMH38yTKM2wxcmiHScxQj2c/urLZNAhk1Qv+D6YSIwWwJgQswmAVq4alWhV G9tg== X-Received: by 10.68.125.169 with SMTP id mr9mr3556615pbb.74.1365007246365; Wed, 03 Apr 2013 09:40:46 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:b4dc:867a:70a7:2b9a? ([2001:4900:1042:100:b4dc:867a:70a7:2b9a]) by mx.google.com with ESMTPS id qs10sm6597321pbb.28.2013.04.03.09.40.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 09:40:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <20130403152054.GA21244@nic.fr> Date: Wed, 3 Apr 2013 12:40:43 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <1A41D9B1-DAD8-4A3F-9B1F-2B0B6918BABF@hopcount.ca> <20130403152054.GA21244@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmvesfspn+kKXDrrAL14M4vvhc7UfGOQWifBpzYAw2V+lSMy//oCm7z+TN5z7oDZQUWO5xh Cc: "dnsop@ietf.org WG" , Paul Wouters , Paul Hoffman Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 16:40:47 -0000 On 2013-04-03, at 11:20, Stephane Bortzmeyer wrote: > On Wed, Apr 03, 2013 at 11:14:24AM -0400, > Joe Abley wrote > a message of 14 lines which said: > >> It would be great to hear such opinions expressed as part of the >> public comment process, > > Is there a way in this process to say "me too"? (A Like button, may be > :-) Because I fully agree with David Burns and do not see the need to > write a long message to just say "+1" Well, you could always comment and say that :-) Joe From jim@rfc1035.com Thu Apr 4 12:45:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD96321F95EA for ; Thu, 4 Apr 2013 12:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 AcBcMHTwugXT for ; Thu, 4 Apr 2013 12:45:46 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 3E30221F95E7 for ; Thu, 4 Apr 2013 12:45:46 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id 246F5CBC41F; Thu, 4 Apr 2013 20:45:38 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: Date: Thu, 4 Apr 2013 20:45:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1503) Cc: dnsop@ietf.org, Paul Hoffman , Joe Abley Subject: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 19:45:47 -0000 On 3 Apr 2013, at 16:11, Paul Wouters wrote: > It's the vendors of equipment supporting DNSSEC that have > the real issues. If they shipped with a root anchor, and their stuff > is offline for 5 years and turned on, their DNS will be broken and = 5011 > isn't going to be useful to them..... Fair enough Paul, but how much of a problem could that realistically be = and is it worth bothering about? I think nothing is needed here except perhaps a statement of the = bleeding obvious: "if you miss too many key rollovers, Very Bad Things = will happen so make sure you have a foolproof way of recovering from = that". eg Have some out of band means of fetching and verifying the = current version of the One True Trust Anchor. From jabley@hopcount.ca Thu Apr 4 12:53:36 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8561921F84D4 for ; Thu, 4 Apr 2013 12:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv5Ja7g6Y+xi for ; Thu, 4 Apr 2013 12:53:35 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DFE6221F84D1 for ; Thu, 4 Apr 2013 12:53:35 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id s35so1266055dak.34 for ; Thu, 04 Apr 2013 12:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=7g57GlFgK1rr2kZngezJ3uUyYxj3Gs48FaubmVZCAvY=; b=HgS4K5Hp1bRCoxPUU/kZXglpyRiNDkBV/caU198me7RaQ6jD4lFvpS5lsspj47CVyV GW2NEww5uliP9BfHDE8q8UG3qSdRI+InYoJNtbskgXaBgloagQUj3uyqoaEfhfkFndBa ALvO9AfrTgSSPnA31Q7IRJ4WmeRpO7ZrfW9v4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=7g57GlFgK1rr2kZngezJ3uUyYxj3Gs48FaubmVZCAvY=; b=lRGkEUgTS91OYT5ezUGUT58pxLMMjnpy1I30Nbhc0jBnMa36BTAa7+r6QH8J3SMpKq NuKBJ5jg2cozDUJGcFchdu/CYA5h/9w3Ulpf0wxY06RGkb+xzNsHRxKyo7RkWWdBQRXO bHe4iqEQts0q0jeoqTfCcf/e390XrNjmFPlEtDnwnLo/wv2wNLqnY3sILcsFplRyYdDL 47EdfmCTSbg3BZyof4WIP0U0snKfV9/azF3BT57UeoFlcEjVSkTmJtkjJogwBLm/vQpI P8HI1fbEVEYwepBzfdUOJt+6ImxKD3asAqVnXsObPcffQ8PL8X5r6G8Qvk4NB8zXPyWA zZFg== X-Received: by 10.68.189.234 with SMTP id gl10mr10579200pbc.93.1365105215523; Thu, 04 Apr 2013 12:53:35 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:25f7:9e0e:660a:7e31? ([2001:4900:1042:100:25f7:9e0e:660a:7e31]) by mx.google.com with ESMTPS id w3sm2717214pbw.23.2013.04.04.12.53.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 12:53:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Thu, 4 Apr 2013 15:53:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <009EF7F3-3793-4449-8D80-8B466563D148@hopcount.ca> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Jim Reid X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlda0oGcUbFDBT/aH2YWS13cWglv6tJVP30/3MHADYZj+ykC2/Zj+gCctv4nHM90HbvWR/S Cc: dnsop@ietf.org, Paul Wouters , Paul Hoffman Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 19:53:36 -0000 On 2013-04-04, at 15:45, Jim Reid wrote: > On 3 Apr 2013, at 16:11, Paul Wouters wrote: >=20 >> It's the vendors of equipment supporting DNSSEC that have >> the real issues. If they shipped with a root anchor, and their stuff >> is offline for 5 years and turned on, their DNS will be broken and = 5011 >> isn't going to be useful to them..... >=20 > Fair enough Paul, but how much of a problem could that realistically = be and is it worth bothering about? I tend to think that regardless of whether the operator of a device is = technical or not, if you pull a 5-year-old anything out of the cupboard = and plug it in only to find it doesn't work, that's almost expected = behaviour. The astonishment comes if it *does* work. Joe From paul.hoffman@vpnc.org Thu Apr 4 13:20:01 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F3421F8C5B for ; Thu, 4 Apr 2013 13:20:01 -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 6VHj9rINfH0K for ; Thu, 4 Apr 2013 13:20:01 -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 E93B721F8C16 for ; Thu, 4 Apr 2013 13:20:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r34KJukm020012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 4 Apr 2013 13:19:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Thu, 4 Apr 2013 13:19:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: "dnsop@ietf.org WG" X-Mailer: Apple Mail (2.1503) Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:20:01 -0000 On Apr 4, 2013, at 12:45 PM, Jim Reid wrote: > On 3 Apr 2013, at 16:11, Paul Wouters wrote: >=20 >> It's the vendors of equipment supporting DNSSEC that have >> the real issues. If they shipped with a root anchor, and their stuff >> is offline for 5 years and turned on, their DNS will be broken and = 5011 >> isn't going to be useful to them..... >=20 > Fair enough Paul, but how much of a problem could that realistically = be and is it worth bothering about? >=20 > I think nothing is needed here except perhaps a statement of the = bleeding obvious: "if you miss too many key rollovers, Very Bad Things = will happen so make sure you have a foolproof way of recovering from = that". We need that statement because it's *not* bleeding obvious. I cannot = think of a single thing built into a 2007-era ISO of a Linux distro that = would have the property similar to "it will automatically give = mysterious results for DNS service". It might have lots of unsafe = software turned on, but none that will say "I'll serve you" but then it = doesn't. > eg Have some out of band means of fetching and verifying the current = version of the One True Trust Anchor. And has the IETF supplied anything like that? If not, should ICANN wait = for the first roll until we have? --Paul Hoffman= From nweaver@icsi.berkeley.edu Thu Apr 4 13:23:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7650221F8D09 for ; Thu, 4 Apr 2013 13:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nFaTLq2Jqzb for ; Thu, 4 Apr 2013 13:23:32 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1337C21F84A6 for ; Thu, 4 Apr 2013 13:23:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 00EC02C4015; Thu, 4 Apr 2013 13:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZRkRnuFWqsSZ; Thu, 4 Apr 2013 13:23:31 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B39E22C4002; Thu, 4 Apr 2013 13:23:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: Date: Thu, 4 Apr 2013 13:23:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: "dnsop@ietf.org WG" , Nicholas Weaver Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:23:32 -0000 On Apr 4, 2013, at 1:19 PM, Paul Hoffman wrote: >> I think nothing is needed here except perhaps a statement of the = bleeding obvious: "if you miss too many key rollovers, Very Bad Things = will happen so make sure you have a foolproof way of recovering from = that". >=20 > We need that statement because it's *not* bleeding obvious. I cannot = think of a single thing built into a 2007-era ISO of a Linux distro that = would have the property similar to "it will automatically give = mysterious results for DNS service". It might have lots of unsafe = software turned on, but none that will say "I'll serve you" but then it = doesn't. Also, there is a LOT of old, NEVER updated, 5 year old networking kit = out there. Well, fortunately they are often clueless about DNSSEC, but = still... From marka@isc.org Thu Apr 4 13:35:37 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF0621F8BC0 for ; Thu, 4 Apr 2013 13:35:37 -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 h3ap3aTwNBvg for ; Thu, 4 Apr 2013 13:35:37 -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 22C2521F8B98 for ; Thu, 4 Apr 2013 13:35:37 -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 73D095F9966; Thu, 4 Apr 2013 20:35:23 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1365107736; bh=YS/yhZthKbXTglSFGncp4lY2pNTaNB/2mvD3DVHLBSk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=TXV6Tvv7XOU70Jw/su38xrQPu8II/He1vMhc4rtzobwE1/+0CIeRb9mjtlK7kcjHS 5fLs5RGgUsKWTfie6IIcBhHis8X9zg2IFKEheh08/e1ZTzbZpvuBkSDjKsEywRbflG /pY4wedg8eNHGiXRhyh8lIBbJ4oRzzZL4R++qj80= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:20b6:722c:ade6:7e2d]) (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 D2278216C40; Thu, 4 Apr 2013 20:35:21 +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 2D1A731F02D2; Fri, 5 Apr 2013 07:35:15 +1100 (EST) To: Nicholas Weaver From: Mark Andrews References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> In-reply-to: Your message of "Thu, 04 Apr 2013 13:23:31 PDT." Date: Fri, 05 Apr 2013 07:35:14 +1100 Message-Id: <20130404203515.2D1A731F02D2@drugs.dv.isc.org> Cc: "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:35:37 -0000 In message , Nicholas Weaver writes: > > On Apr 4, 2013, at 1:19 PM, Paul Hoffman wrote: > >> I think nothing is needed here except perhaps a statement of the > >> bleeding obvious: "if you miss too many key rollovers, Very Bad Things > >> will happen so make sure you have a foolproof way of recovering from > >> that". > > > > We need that statement because it's *not* bleeding obvious. I cannot > > think of a single thing built into a 2007-era ISO of a Linux distro that > > would have the property similar to "it will automatically give mysterious > > results for DNS service". It might have lots of unsafe software turned > > on, but none that will say "I'll serve you" but then it doesn't. > > Also, there is a LOT of old, NEVER updated, 5 year old networking kit out > there. Well, fortunately they are often clueless about DNSSEC, but > still... > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop The real problem here is that 5011 is a hack. It overloads SEP. It makes for a bigger DNSKEY rrset. It doesn't provide for per zone refresh policy. It doesn't give guidance for effectivity interval for DNSKEYs. Validators need to have end dates for DNSKEYS. If it starts up after that date it goes to all insecure. At the moment a DNSKEY is valid till the end of time. You can recover relatively easily from all insecure. Recovering from all bogus is much harder. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jabley@hopcount.ca Thu Apr 4 13:37:07 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95F821F8C45 for ; Thu, 4 Apr 2013 13:37:07 -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 yXla5QlRVrGo for ; Thu, 4 Apr 2013 13:37:06 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id A963E21F8BA6 for ; Thu, 4 Apr 2013 13:37:06 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id x11so1621906pdj.38 for ; Thu, 04 Apr 2013 13:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=eL/5Xc61wmAEv1fiYEao99ytQdbn0LKkyNUCCrhCm28=; b=GTnvPEWCjYMh1CUvmscO3uLsRN7gUTkrrPTU2x0ALBjDarLhLxMhOKY1Oa21LqWau9 L3gkV4kbG6hV2PPrgIvG5yn9qTiaLDdcZwEI5dzplu54apxz3+f8hXFa4kvSx85gSN09 LVyG1LykALt8f5OU1gg5fMQrQk+CApkOgVMAo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=eL/5Xc61wmAEv1fiYEao99ytQdbn0LKkyNUCCrhCm28=; b=OS56boSz0YEAmfzHWezkdbddHr1HCagxB+m5qncFV6RyrFHxEN+N2Dd+r3rf8AVIfG La55S4hOJDCwrEzL3kl/DtHLw1rqxY7wA/MAwSqiFAD+GnR1uoMcz6IuEC5fBpDS8Rwz FKQHyHWOeWnTGQFQJKQwS/uMXNlINUQBcW/uHM/DeunT2spMwks+yHBtdVKEtImTPrTN VOpHx5DYauSwwNHuOqz/HGEbj2GT+FRYKqGJh3kW3td4KoIgfR8xHHY+FyPibJnXk96m exaWmL0Ft/0ClvLAYpHGiFAOcfQa33DxiDNvGubdLFzecsIPv+EDKQNCujxSxaqxNXbT dEfw== X-Received: by 10.66.235.3 with SMTP id ui3mr11627607pac.200.1365107826433; Thu, 04 Apr 2013 13:37:06 -0700 (PDT) Received: from dh23.r1.hopcount.ca (dh23.r1.hopcount.ca. [199.212.90.23]) by mx.google.com with ESMTPS id kt5sm11397525pbc.30.2013.04.04.13.37.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 13:37:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Thu, 4 Apr 2013 16:37:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66C6FD3E-7D51-4D5E-B4DE-2B9F35A9D8D3@hopcount.ca> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Nicholas Weaver X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlGvWVzDXGvSziXDjVc+u9TYwJNZQ1pkuTOtUNTAMk+tXAPMVHaZy4ALFDQCufm7WY2H9cY Cc: "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:37:08 -0000 On 2013-04-04, at 16:23, Nicholas Weaver = wrote: >=20 > On Apr 4, 2013, at 1:19 PM, Paul Hoffman = wrote: >>> I think nothing is needed here except perhaps a statement of the = bleeding obvious: "if you miss too many key rollovers, Very Bad Things = will happen so make sure you have a foolproof way of recovering from = that". >>=20 >> We need that statement because it's *not* bleeding obvious. I cannot = think of a single thing built into a 2007-era ISO of a Linux distro that = would have the property similar to "it will automatically give = mysterious results for DNS service". It might have lots of unsafe = software turned on, but none that will say "I'll serve you" but then it = doesn't. >=20 > Also, there is a LOT of old, NEVER updated, 5 year old networking kit = out there. Well, fortunately they are often clueless about DNSSEC, but = still... I'm guessing that *all* kit today that has been on the shelf for the = past 5 years is clueless about the current root zone trust anchor, = considering that we generated it less than 3 years ago :-) Joe From jabley@hopcount.ca Thu Apr 4 13:39:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAAC21F8C7D for ; Thu, 4 Apr 2013 13:39:35 -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 2ZdoEfFZZAGY for ; Thu, 4 Apr 2013 13:39:35 -0700 (PDT) Received: from mail-da0-x22e.google.com (mail-da0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABDB21F8C16 for ; Thu, 4 Apr 2013 13:39:35 -0700 (PDT) Received: by mail-da0-f46.google.com with SMTP id y19so1277924dan.33 for ; Thu, 04 Apr 2013 13:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=1G4Lq0KGADOTM3u6RFOdZ+wBox/yzvXOdZTgFhsn10E=; b=ZAslzSuxyD/DWaU5PiMQTpy2mg8+hHrqeLUhVTT7IkfDxO2/JeAW7MJ8HrLB4blqRA mOR0h/eAvTM3/OtQ/BgBoaOHydeE8ZOc4qcQR9v90WK087PtSpyTcscGDmBsKg00C4mz cVPVeH4EIw354KhR0XOPdQ4IdStjc/jNwhIUU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=1G4Lq0KGADOTM3u6RFOdZ+wBox/yzvXOdZTgFhsn10E=; b=LnKxsgA4nQx8vrxvrdxIyfqwuEsTlhF5Jw84gZj8qTMlTnRsR3Cuek1SJLLodxl7rC xP/lbN7jzjFOWVktMwfhO6HV1aN6kX+nId9YeiIIqdthyvN7x7SGWkHfJWsb5Add55up ccLK8tamL0qpNnN9/bfN494HYxL/b1ZyuN/O8JrgCKeHcv4EOsi9YSizsJZCVIF3VnN9 OcKOnu3lYCOoafqaNXXWr+sGJLor78M3VyYiw8pszyHXnISZdWYrmXqlgjtGYw3Wuleq JtBKBjopXRyw1VIGVNtQp3oKsApYASRJXRPBDwyUc/ky3mSQ92aMnr565DxJeYtegTQS 7ALA== X-Received: by 10.66.183.33 with SMTP id ej1mr11417674pac.8.1365107975149; Thu, 04 Apr 2013 13:39:35 -0700 (PDT) Received: from dh23.r1.hopcount.ca (dh23.r1.hopcount.ca. [199.212.90.23]) by mx.google.com with ESMTPS id 1sm11402422pba.32.2013.04.04.13.39.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 13:39:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Thu, 4 Apr 2013 16:39:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4D64FD8F-30B4-46D5-9EDC-D7D88ADB20B5@hopcount.ca> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk9lpRIdNzfAAgKJKqie6DpKtel394ZaNFu0h+3Ys8kmxoFHlHM2ywNiKhCfFCaxdxetB1+ Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:39:35 -0000 On 2013-04-04, at 16:19, Paul Hoffman wrote: >> eg Have some out of band means of fetching and verifying the current = version of the One True Trust Anchor. >=20 > And has the IETF supplied anything like that? If not, should ICANN = wait for the first roll until we have? ICANN has published documentation for exactly this, and efforts to = produce equivalent documentation within the IETF (to which, once stable, = the published procedures for root zone KSK management can refer to) is = ongoing. You know this, so I presume you meant something oblique by your comment? Joe= From jabley@hopcount.ca Thu Apr 4 13:46:45 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4636421F8D8C for ; Thu, 4 Apr 2013 13:46:45 -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 Xv0IhTcvt2Ps for ; Thu, 4 Apr 2013 13:46:44 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id A428221F8D41 for ; Thu, 4 Apr 2013 13:46:44 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id q11so1626823pdj.25 for ; Thu, 04 Apr 2013 13:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ALwq38POpqQ12YanPsU0nHzucaOppggSsbaQYfzsHUk=; b=HDiI3PPICtgMqfj9l7SbINE0VGyYw5gN7q8nuSoiEa0Y4z2g5j2CwS+lx1saCyNCe0 jomwknYKdjvZicsfBRZ5Db/vPyf6icH1dy6opglRi+EuPhramEFHuVxqViqaGhqCoF7z 5Xsu6+NTSmCASrHxC9Ejxfkx2Tg+vW8E3pmxY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ALwq38POpqQ12YanPsU0nHzucaOppggSsbaQYfzsHUk=; b=gFXrJGVMu9mO8ntR9Vz+7LbqZG8Y8xDotRbIvPepUd6gui3gLO1M3TZhOOHJTB89P7 fN5XYjaMIyhTDCSHYEGKG8690O1TOa4Apoak4aeV3eUIDKhV58ctqbNUx0VfeFcxD/mu V4NrgsTBLrFKHFN32YThLrTUUYyTk5W2ky7Xta4BCvReO4/haSFZ8aw2mFkSgSxgdfZN yOwFudKbfUmMVT0eemB7i8x3dWbyOv7OQun7U3LCjj+7dmAX7oNJyMd+EDlXlyfRXaHf jREQNdf71FTEt1tVGb8QZKE3OpDSH90aB7h9VKFWF2WTlgvbBZNnFPOnWDxCUBHEeVrG SU9w== X-Received: by 10.68.44.195 with SMTP id g3mr10888556pbm.141.1365108404397; Thu, 04 Apr 2013 13:46:44 -0700 (PDT) Received: from dh23.r1.hopcount.ca (dh23.r1.hopcount.ca. [199.212.90.23]) by mx.google.com with ESMTPS id cn1sm11468247pbb.7.2013.04.04.13.46.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 13:46:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <20130404203515.2D1A731F02D2@drugs.dv.isc.org> Date: Thu, 4 Apr 2013 16:46:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130404203515.2D1A731F02D2@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnvLjJi9cwVuCHRLF6ThbHD6V5frIhg9Q/JfVrAER4RRZcm6aJi4pSBM+uD1QtZteneS+kC Cc: "dnsop@ietf.org WG" , Nicholas Weaver , Paul Hoffman Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:46:45 -0000 On 2013-04-04, at 16:35, Mark Andrews wrote: > Validators need to have end dates for DNSKEYS. If it starts up > after that date it goes to all insecure. http://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00 was a first attempt to describe how a validator should bootstrap itself. I got zero feedback that anybody was interested in that problem space, = and the draft never went any further. I continue to think that behaviour = upon cold boot is important to specify however, and if root zone KSK = rollover thoughts have changed peoples minds about its usefulness, I'd = gladly pick it up again. It needs some work (any sentence that includes the word "certificate" is = liable to make Mr Hoffman shake his fist in its current form), but I = think the basic approach described has merit. In general, if we acknowledge for the purposes of this discussion that = root zone KSK rollovers will happen, and will happen often enough to = care about mitigating damage during roll, I think we need a two-pronged = approach to this problem space: 1. Use 5011 or some similar mechanism to accommodate key rollovers (for = devices that are turned on often enough to be able to do that) 2. Carefully specify bootstrapping behaviour so that any cold-start of a = long-dormant validator can be handled in some sane way. Joe= From paul@nohats.ca Thu Apr 4 13:46:52 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DA321F8F0F for ; Thu, 4 Apr 2013 13:46:52 -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 RJvlq3wyliUr for ; Thu, 4 Apr 2013 13:46:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id BB66521F8EF2 for ; Thu, 4 Apr 2013 13:46:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zhbmm0463z7LT; Thu, 4 Apr 2013 16:46:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OZhP1Ic-uoh6; Thu, 4 Apr 2013 16:46:46 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 4 Apr 2013 16:46:46 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 2F4FB80BCA; Thu, 4 Apr 2013 16:46:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 245AA80442; Thu, 4 Apr 2013 16:46:47 -0400 (EDT) Date: Thu, 4 Apr 2013 16:46:47 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:46:52 -0000 On Thu, 4 Apr 2013, Paul Hoffman wrote: >> I think nothing is needed here except perhaps a statement of the bleeding obvious: "if you miss too many key rollovers, Very Bad Things will happen so make sure you have a foolproof way of recovering from that". > > We need that statement because it's *not* bleeding obvious. I cannot think of a single thing built into a 2007-era ISO of a Linux distro that would have the property similar to "it will automatically give mysterious results for DNS service". It might have lots of unsafe software turned on, but none that will say "I'll serve you" but then it doesn't. > >> eg Have some out of band means of fetching and verifying the current version of the One True Trust Anchor. > > And has the IETF supplied anything like that? If not, should ICANN wait for the first roll until we have? The only thing we have is the ICANN PEM bundle, and unbound-anchor like mechanisms where we try to get the root key verified by the signed certificate of ICANN. But it all depends on the security of the CA's, and an ever lasting URL at the icann site for the bundle and the continued publication of the certs and root keys there. None of which I believe is codified in an RFC. Paul From paul@nohats.ca Thu Apr 4 13:50:03 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6303E21F8633 for ; Thu, 4 Apr 2013 13:50:03 -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 ocbnugluBs6n for ; Thu, 4 Apr 2013 13:50:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id F0E8B21F8629 for ; Thu, 4 Apr 2013 13:49:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZhbrM5ZVrz7LT; Thu, 4 Apr 2013 16:49:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id sGs0WGF-ww3D; Thu, 4 Apr 2013 16:49:55 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 4 Apr 2013 16:49:54 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 9748480BCA; Thu, 4 Apr 2013 16:49:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 80CDA80442; Thu, 4 Apr 2013 16:49:55 -0400 (EDT) Date: Thu, 4 Apr 2013 16:49:55 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: <66C6FD3E-7D51-4D5E-B4DE-2B9F35A9D8D3@hopcount.ca> Message-ID: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <66C6FD3E-7D51-4D5E-B4DE-2B9F35A9D8D3@hopcount.ca> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsop@ietf.org WG" , Nicholas Weaver , Paul Hoffman Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:50:03 -0000 On Thu, 4 Apr 2013, Joe Abley wrote: >>> We need that statement because it's *not* bleeding obvious. I cannot think of a single thing built into a 2007-era ISO of a Linux distro that would have the property similar to "it will automatically give mysterious results for DNS service". It might have lots of unsafe software turned on, but none that will say "I'll serve you" but then it doesn't. >> >> Also, there is a LOT of old, NEVER updated, 5 year old networking kit out there. Well, fortunately they are often clueless about DNSSEC, but still... > > I'm guessing that *all* kit today that has been on the shelf for the past 5 years is clueless about the current root zone trust anchor, considering that we generated it less than 3 years ago :-) But we designed DNSSEC in such a way that the 5 year old kit will still work as (insecurely) as it was designed 5 years ago. That's not true if we find root key copies in firmware now. But we all had these discussions before, we had a draft for a special zone that would contain historic root keys, etc. We just never found something that would properly work (I believe the thread was entitled "big router vendor" or something along those lines) Paul From paul.hoffman@vpnc.org Thu Apr 4 14:00:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE98921F8D2C for ; Thu, 4 Apr 2013 14:00:46 -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 OqK8KkHKKkAJ for ; Thu, 4 Apr 2013 14:00:46 -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 7841421F8556 for ; Thu, 4 Apr 2013 14:00:46 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r34L0h2c021672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Apr 2013 14:00:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <4D64FD8F-30B4-46D5-9EDC-D7D88ADB20B5@hopcount.ca> Date: Thu, 4 Apr 2013 14:00:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6E168E77-4D1D-4554-9D40-CA5AF96F8259@vpnc.org> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <4D64FD8F-30B4-46D5-9EDC-D7D88ADB20B5@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:00:47 -0000 On Apr 4, 2013, at 1:39 PM, Joe Abley wrote: >=20 > On 2013-04-04, at 16:19, Paul Hoffman wrote: >=20 >>> eg Have some out of band means of fetching and verifying the current = version of the One True Trust Anchor. >>=20 >> And has the IETF supplied anything like that? If not, should ICANN = wait for the first roll until we have? >=20 > ICANN has published documentation for exactly this, and efforts to = produce equivalent documentation within the IETF (to which, once stable, = the published procedures for root zone KSK management can refer to) is = ongoing. >=20 > You know this, so I presume you meant something oblique by your = comment? You must have misread the verb tense in my message. :-) "has supplied" = is quite different than "efforts is ongoing". This is a serious question: would it be reasonable for ICANN to do a key = roll when there is no IETF documentation on how to recover from missed = rolls? Some might say "yes", but you can tell I would not. While I appreciate that ICANN wrote a document, unless you want to say = "this is the the ICANN document you should use to deal with the = operation we are about to perform", it needs to have an RFC stamp on it. --Paul Hoffman= From jim@rfc1035.com Thu Apr 4 14:16:44 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19E421F8DB4 for ; Thu, 4 Apr 2013 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311] 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 uFGEHd+zwP45 for ; Thu, 4 Apr 2013 14:16:43 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4AE21F8DAC for ; Thu, 4 Apr 2013 14:16:43 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id 4A432CBC41F; Thu, 4 Apr 2013 22:16:42 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: Date: Thu, 4 Apr 2013 22:16:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F3AE94F-33C8-4CC4-8055-C8B2181D0901@rfc1035.com> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: dnsop@ietf.org Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:16:45 -0000 On 4 Apr 2013, at 21:19, Paul Hoffman wrote: >> I think nothing is needed here except perhaps a statement of the = bleeding obvious: "if you miss too many key rollovers, Very Bad Things = will happen so make sure you have a foolproof way of recovering from = that". >=20 > We need that statement because it's *not* bleeding obvious. Words fail me. If this really does need to be written down somewhere, = then let's do it. I'll be happy to help write such a document. And add a = section on what bears do in the woods. :-) Though I understand ICANN = already has published something which covers this. Well OK, the key = rollover bit... > I cannot think of a single thing built into a 2007-era ISO of a Linux = distro that would have the property similar to "it will automatically = give mysterious results for DNS service". It might have lots of unsafe = software turned on, but none that will say "I'll serve you" but then it = doesn't. There's no need to discuss what things 2007 vintage Linux gets wrong or = right. I doubt if any production software from that time did anything = remotely useful with DNSSEC validation, but let that pass. The issue should be making sure current and future platforms that come = with DNSSEC validation enabled by default have got some sort of safety = net to recover from missing a key rollover. I would hope/expect anyone = shipping such stuff today or in the future would have the clue to do = that without needing to be told. It seems improbable anyone would = hard-wire any fundamental configuration information when it's already = known that data MUST change from time to time. Though if someone does do = that, fine: it's their look-out. =20 >> eg Have some out of band means of fetching and verifying the current = version of the One True Trust Anchor. >=20 > And has the IETF supplied anything like that? Not yet but ICANN has done this IIRC. > If not, should ICANN wait for the first roll until we have? No. A certain level of clue is needed to do DNSSEC validation and get it = right. This *has* to include providing a reliable way to recover from = losing the fundamental trust anchor. YMMV. At present the validating = DNSSEC installed base is fairly small and doesn't yet have to rely on = Standards-Track RFCs (or whatever) to tell them what to do. It would of = course be nice to have these RFCs. However IMO their absence is not a = showstopper for rolling the root key. DNSSEC validation is still = something for consenting adults who (should) know what they are doing.= From jabley@hopcount.ca Thu Apr 4 14:20:08 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEFD21F8DAC for ; Thu, 4 Apr 2013 14:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F63s3sKUNk+S for ; Thu, 4 Apr 2013 14:20:07 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 691E821F8E99 for ; Thu, 4 Apr 2013 14:20:07 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id p1so1290290dad.27 for ; Thu, 04 Apr 2013 14:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ql9n0CdT+Hdo6U0BjOssiHuQ3BBc7kL+yqvALvBl/PE=; b=Y/6rzefAiIrmjqVYcnLgp7GnpjK8awsjijsU2NVZKwo3c89JU2v94E9oXqavwPzIjJ DQx/nBMOktHXmA3Q0KLqBYkNBTuh2Iu7byIQepe0/iwgsBY4DdzcUtSrpTwto1S0eZGR Hd4bgSA3CJY0t+CjJwNchj0mAmWAsvyzJX7g0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ql9n0CdT+Hdo6U0BjOssiHuQ3BBc7kL+yqvALvBl/PE=; b=nCYRgvmOCRsOToc/CqUq9uLxyB19Ja+osaaIPinEg/EVPQs47OredwSlH4wXwxfBzI 3IcWCKtiw0JdrFAqBz0FV/41U+cFHNakNJzsPKzoGPs+NKHG+/z7O9nzsT91v1MOX+QZ YvQ7Fk5adT81ONuFK1VStqTL/3Yxg/rjSCq9wmXeqPu8WhQeB+WVUwlY1rlRjTmyHI+U DuPrA1XJ1M7jkzOgcWLiWi3Uf2+v85PKNjU2tL99N2Wzjc/fVHIV1vgtAtF4x6lw+wvB tBYuQjjg916KYzntIrj0P74jT9NlmokFapsoENtpqJHmV6ochpQ/nDrUYucsR6Q0cJVd uu0g== X-Received: by 10.68.177.162 with SMTP id cr2mr10766352pbc.179.1365110407171; Thu, 04 Apr 2013 14:20:07 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:25f7:9e0e:660a:7e31? ([2001:4900:1042:100:25f7:9e0e:660a:7e31]) by mx.google.com with ESMTPS id iv3sm11486758pbc.40.2013.04.04.14.20.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 14:20:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <6E168E77-4D1D-4554-9D40-CA5AF96F8259@vpnc.org> Date: Thu, 4 Apr 2013 17:20:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <4D64FD8F-30B4-46D5-9EDC-D7D88ADB20B5@hopcount.ca> <6E168E77-4D1D-4554-9D40-CA5AF96F8259@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmxAPVVqrmQr5QmOiIMhiagg4uxeIcL11+7BkJ4fvs+1WnxZwBt+cp39EkKuQ20EWPvYoNm Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:20:08 -0000 On 2013-04-04, at 17:00, Paul Hoffman wrote: > You must have misread the verb tense in my message. :-) "has supplied" = is quite different than "efforts is ongoing". Well, what we have is a design that was put together by ICANN, Verisign = and NTIA (the three organisations that maintain and publish the root = zone) that was widely discussed by e-mail and in person across five = continents prior to July 2010. We heard no dissent or suggestions to = change, so that's what we went with. It's entirely understood that lack = of feedback doesn't mean improvements can't be made; my point is the = origins of the design work, and the venues in which it was widely = circulated for comment. There is no IETF-produced documentation for any operational aspect of = the system. It was all designed and documented by the root zone = partners. The I-D referred to earlier (as a successor to the TA = retrieval document we published in July 2010) was not intended to be an = IETF work product; it was instead intended to be an individual = submission documenting an operational system of relevance to the IETF, = published in the RFC series for ease of citation. > This is a serious question: would it be reasonable for ICANN to do a = key roll when there is no IETF documentation on how to recover from = missed rolls? Some might say "yes", but you can tell I would not. Ah, now you're talking about something different -- you're talking about = IETF guidance to the relying parties of the system rather than IETF = guidance on how the system should be operated. > While I appreciate that ICANN wrote a document, unless you want to say = "this is the the ICANN document you should use to deal with the = operation we are about to perform", it needs to have an RFC stamp on it. That sounds like exactly what we will say, with the minor correction = that the root zone partners are working together on this; it's not all = ICANN's work. If there was relevant IETF work that we could incorporate into the = system, surely we would do so (as we did with 4033-5 and 5011). But the = design of the system and the operational procedures associated with it = are not products of the IETF, and given the contractual framework within = which the work takes place it's not obvious how they could be. Joe= From jim@rfc1035.com Thu Apr 4 14:25:51 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE0821F90A1 for ; Thu, 4 Apr 2013 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.156, 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 CtIcMZkO3lN0 for ; Thu, 4 Apr 2013 14:25:51 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1C98121F9007 for ; Thu, 4 Apr 2013 14:25:51 -0700 (PDT) Received: from [IPv6:::1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id B2083CBC41F; Thu, 4 Apr 2013 22:25:49 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: Date: Thu, 4 Apr 2013 22:25:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <098C0D15-EFB6-467A-9027-9BA7B260933F@rfc1035.com> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130404203515.2D1A731F02D2@drugs.dv.isc.org> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: dnsop@ietf.org, Nicholas Weaver , Paul Hoffman Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:25:51 -0000 On 4 Apr 2013, at 21:46, Joe Abley wrote: > I think we need a two-pronged approach to this problem space: >=20 > 1. Use 5011 or some similar mechanism to accommodate key rollovers = (for devices that are turned on often enough to be able to do that) >=20 > 2. Carefully specify bootstrapping behaviour so that any cold-start of = a long-dormant validator can be handled in some sane way. +1 An enumeration of the solutions of this problem space doesn't need to be = done before the first live root zone key rollover.* IMO, there's little = that could break and if there was any collateral damage it would happen = in places where there's enough clue to put things right. *Did anything significant break when the rollover from the DURZ key = happened? OK, that was moving from a state where nothing validated to = where things did validate, but still... From paul.hoffman@vpnc.org Thu Apr 4 14:32:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CE421F8CCB for ; Thu, 4 Apr 2013 14:32:11 -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 Q-qgk37eLGa6 for ; Thu, 4 Apr 2013 14:32:11 -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 6212D21F8CBE for ; Thu, 4 Apr 2013 14:32:11 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r34LW8BJ023091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Apr 2013 14:32:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Thu, 4 Apr 2013 14:32:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E3DEC92-3583-43C9-B2ED-8BD03FF871E5@vpnc.org> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <4D64FD8F-30B4-46D5-9EDC-D7D88ADB20B5@hopcount.ca> <6E168E77-4D1D-4554-9D40-CA5AF96F8259@vpnc.org> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:32:11 -0000 On Apr 4, 2013, at 2:20 PM, Joe Abley wrote: > On 2013-04-04, at 17:00, Paul Hoffman wrote: >> While I appreciate that ICANN wrote a document, unless you want to = say "this is the the ICANN document you should use to deal with the = operation we are about to perform", it needs to have an RFC stamp on it. >=20 > That sounds like exactly what we will say, with the minor correction = that the root zone partners are working together on this; it's not all = ICANN's work. That sounds fine to me, then. It's different than what Jim said at the = beginning of this thread ("it's obvious"), and it gives a way forwards. FWIW, I don't think any of this needs to be in the IETF; it just needs = to be in a stable place that ICANN points to, and that is maintained. --Paul Hoffman= From marka@isc.org Thu Apr 4 19:12:19 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F399121F9681 for ; Thu, 4 Apr 2013 19:12:18 -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 Eh4Xc3Kxj64d for ; Thu, 4 Apr 2013 19:12:18 -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 6AB6121F967F for ; Thu, 4 Apr 2013 19:12:18 -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 E678A5F9959; Fri, 5 Apr 2013 02:12:05 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1365127936; bh=HlSZFkqdhIWBn/tj5IaubY8L2S/j59tYRT4FaspPHsU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=GgtYoC3IfsCWle6VH/Tosh2FtGK4Kv1evEATErO4foM7/Mzp7UadeEe4XQvu8/JH1 CVMg7F33RUEoPJEtYRlmBqIesxdeo5AU5p+Oa4pQZEXd5B+2tHKR9Y4ewn2huCb5PA BVbf7/PUsJizwuhkenCRoh0iNnchC2JoW8jMv1OI= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:20b6:722c:ade6:7e2d]) (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 550B1216C40; Fri, 5 Apr 2013 02:12:04 +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 663E631F7AA9; Fri, 5 Apr 2013 13:11:56 +1100 (EST) To: Jim Reid From: Mark Andrews References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130404203515.2D1A731F02D2@drugs.dv.isc.org> <098C0D15-EFB6-467A-9027-9BA7B260933F@rfc1035.com> In-reply-to: Your message of "Thu, 04 Apr 2013 22:25:48 BST." <098C0D15-EFB6-467A-9027-9BA7B260933F@rfc1035.com> Date: Fri, 05 Apr 2013 13:11:56 +1100 Message-Id: <20130405021156.663E631F7AA9@drugs.dv.isc.org> Cc: dnsop@ietf.org, Nicholas Weaver , Joe Abley , Paul Hoffman Subject: Re: [DNSOP] lost key rollovers considered harmful X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 02:12:19 -0000 > In message <098C0D15-EFB6-467A-9027-9BA7B260933F@rfc1035.com>, Jim Reid > writes: > *Did anything significant break when the rollover from the DURZ key > happened? OK, that was moving from a state where nothing validated to > where things did validate, but still... This not the same. This is from "usable to usable" not "unusable to usable". -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Sat Apr 6 01:55:25 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6092421F8D01 for ; Sat, 6 Apr 2013 01:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_QP_LONG_LINE=1.396, 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 5iJTB-EGlP0e for ; Sat, 6 Apr 2013 01:55:24 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 537C721F8BE8 for ; Sat, 6 Apr 2013 01:55:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from 29.1.120.78.rev.sfr.net ([78.120.1.29]:52794 helo=[192.168.1.66]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1UOOu7-00042y-qu (Exim 4.72) (return-path ); Sat, 06 Apr 2013 09:55:19 +0100 References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130403151735.GA20820@nic.fr> <20130403163826.GA46759@isc.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20130403163826.GA46759@isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <76E16FA9-84E0-4091-9ECA-5DB0A5BCA90A@dotat.at> X-Mailer: iPhone Mail (10B144) From: Tony Finch Date: Sat, 6 Apr 2013 09:55:14 +0100 To: Evan Hunt Sender: Tony Finch Cc: "dnsop@ietf.org WG" , Paul Hoffman , Joe Abley Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 08:55:25 -0000 On 3 Apr 2013, at 17:38, Evan Hunt wrote: >=20 > Then there's the issue Paul mentioned -- gear configured with a root KSK > that gets switched off and not rebooted for a few months or years, and the= n > no longer works and can't recover. Validator vendors have to provide an out-of-band trust anchor update mechani= sm to cope with this. It needs to be coded and included in long-term support= releases of validators and operating systems before rollover, I think. I am not sure if ICANN intend their trust anchor download server to be used f= or this purpose or if vendors are expected to provision their own mirrors. I= also don't know how to assess the trustworthiness of ICANN's signatures on t= he trust anchor. Tony. -- f.anthony.n.finch http://dotat.at/= From jabley@hopcount.ca Sat Apr 6 02:04:13 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BF821F8CC9 for ; Sat, 6 Apr 2013 02:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60EH9AMLBdyT for ; Sat, 6 Apr 2013 02:04:13 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5217721F8C4F for ; Sat, 6 Apr 2013 02:04:13 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id t2so385583qcq.0 for ; Sat, 06 Apr 2013 02:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=nLiiO57fMx3k/7wdgSjQSR1/mGh4ME/snoCWg6H/jLI=; b=dBzQjo4Guz1aZlTbY4gKtsE3jI5moCYkCPhTVErlW8PWPBYGqKeDBb+lLgjD8liV3L /h9bk7kukYLHUkBqvLvCxVyfRQyuzLc9i8Idh9EmpJGQMc4YnXlIwm0AuyPDiRx5sFTl IKKNVjC7JSrXN0tjurnYlYNOTwzBTnnQjLX4U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=nLiiO57fMx3k/7wdgSjQSR1/mGh4ME/snoCWg6H/jLI=; b=U03hzUX0PtwxiG8J168dLfYyjK7eFh1ZCOGh0H5ShBKCh1VGnZTDdzbzpf5Qt1n40q cTiF3QIHWqD6Sc2PqmsKSdIJSwRY4aDz64BHy8TXAl/lXnzuU10y1G5lgqWxrTecT8cB /O2wv9Qgt6wtuOpg8G+HftLLGKYA7STS7j868+Hj09Ac07TsBiT2/f6yOuu7L4OKzUbp rnRCIW+l0Tvmtk5KbYPbK7nishwbwkTPDRdru7MdX39Hs0KBzTVnTDrlwsVoChWKZjrb p+JgEx5edZH8ygkF4lj/NjP7Osjtgbzyi1e7eV6zwRmq6VKFqYnMgVVUztznWfG1FGVJ mrUw== X-Received: by 10.224.51.18 with SMTP id b18mr1040732qag.50.1365239052715; Sat, 06 Apr 2013 02:04:12 -0700 (PDT) References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130403151735.GA20820@nic.fr> <20130403163826.GA46759@isc.org> <76E16FA9-84E0-4091-9ECA-5DB0A5BCA90A@dotat.at> From: Joe Abley Mime-Version: 1.0 (1.0) In-Reply-To: <76E16FA9-84E0-4091-9ECA-5DB0A5BCA90A@dotat.at> Date: Sat, 6 Apr 2013 17:04:09 +0800 Message-ID: <8811862356902250422@unknownmsgid> To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnE+SmsEH4Uugk8Ar76MarRQB+duf2SV25ObosjSj21zDB1HyVyu/1MVIghAEgbFK6adS9i Cc: Evan Hunt , "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 09:04:14 -0000 On 2013-04-06, at 16:55, Tony Finch wrote: > On 3 Apr 2013, at 17:38, Evan Hunt wrote: >> >> Then there's the issue Paul mentioned -- gear configured with a root KSK >> that gets switched off and not rebooted for a few months or years, and then >> no longer works and can't recover. > > Validator vendors have to provide an out-of-band trust anchor update mechanism to cope with this. It needs to be coded and included in long-term support releases of validators and operating systems before rollover, I think. draft-jabley-dnsop-validator-bootstrap. > I am not sure if ICANN intend their trust anchor download server to be used for this purpose or if vendors are expected to provision their own mirrors. Our server is fine. Others' servers are also fine, although we would likely prefer to wrap some small process around contact info, notifications when there is new content, etc. > I also don't know how to assess the trustworthiness of ICANN's signatures on the trust anchor. draft-jabley-dnsop-validator-bootstrap. There is some work required on the details, but the intended direction should be clear. Joe From fanf2@hermes.cam.ac.uk Sat Apr 6 02:04:51 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5868221F8DA0 for ; Sat, 6 Apr 2013 02:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.274 X-Spam-Level: X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 kZTlYZwHfdo8 for ; Sat, 6 Apr 2013 02:04:50 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5868F21F8D94 for ; Sat, 6 Apr 2013 02:04:50 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from 29.1.120.78.rev.sfr.net ([78.120.1.29]:52797 helo=[192.168.1.66]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1UOP3I-0006IA-rb (Exim 4.72) (return-path ); Sat, 06 Apr 2013 10:04:48 +0100 References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <43A8B5EA-7C4A-4C53-8479-075C85428EE4@dotat.at> X-Mailer: iPhone Mail (10B144) From: Tony Finch Date: Sat, 6 Apr 2013 10:04:43 +0100 To: Paul Wouters Sender: Tony Finch Cc: "dnsop@ietf.org WG" , Paul Hoffman , Joe Abley Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 09:04:51 -0000 On 3 Apr 2013, at 16:11, Paul Wouters wrote: > It's the vendors of equipment supporting DNSSEC that have > the real issues. If they shipped with a root anchor, and their stuff > is offline for 5 years and turned on, their DNS will be broken and 5011 > isn't going to be useful to them..... The real problem occurs when the latest release of the validator software wa= s published before the rollover, and you install it after the rollover. It i= s perfectly reasonable to install software that is a few months old. Tony. -- f.anthony.n.finch http://dotat.at/= From fanf2@hermes.cam.ac.uk Sat Apr 6 02:22:36 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227C821F8D2C for ; Sat, 6 Apr 2013 02:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 DEGt0pug7ZSr for ; Sat, 6 Apr 2013 02:22:35 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8E22E21F8C04 for ; Sat, 6 Apr 2013 02:22:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from 29.1.120.78.rev.sfr.net ([78.120.1.29]:52809 helo=[192.168.1.66]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1UOPKU-0001Q8-r0 (Exim 4.72) (return-path ); Sat, 06 Apr 2013 10:22:34 +0100 References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130403151735.GA20820@nic.fr> <20130403163826.GA46759@isc.org> <76E16FA9-84E0-4091-9ECA-5DB0A5BCA90A@dotat.at> <8811862356902250422@unknownmsgid> Mime-Version: 1.0 (1.0) In-Reply-To: <8811862356902250422@unknownmsgid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B144) From: Tony Finch Date: Sat, 6 Apr 2013 10:22:24 +0100 To: Joe Abley Sender: Tony Finch Cc: Evan Hunt , "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 09:22:36 -0000 On 6 Apr 2013, at 10:04, Joe Abley wrote: > On 2013-04-06, at 16:55, Tony Finch wrote: >>=20 >> Validator vendors have to provide an out-of-band trust anchor update mech= anism to cope with this. It needs to be coded and included in long-term supp= ort releases of validators and operating systems before rollover, I think. >=20 > draft-jabley-dnsop-validator-bootstrap. Still needs implementation. My point about trustworthiness is that there is (as far as I know) no docume= ntation of how the private keys are managed for the certificates / signature= s on the trust anchor files, which rather undermines the elaborate root KSK m= anagement. I am also worried about being vulnerable to a screwup by any numb= er of CAs; it would be good to pin the list of CA certs that might be used t= o verify the DNS trust anchor signatures. Tony. -- f.anthony.n.finch http://dotat.at/= From jabley@hopcount.ca Sat Apr 6 02:28:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9421F8B49 for ; Sat, 6 Apr 2013 02:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.500, 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 g+xY-4ZxxV2n for ; Sat, 6 Apr 2013 02:28:34 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 5011821F8B45 for ; Sat, 6 Apr 2013 02:28:34 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so405298qeb.33 for ; Sat, 06 Apr 2013 02:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=HFt1/TsR8+hPj/hMYroULBrvlABrAW8lsgdOIuJwU+0=; b=mNPpoADEFhAbyOnDim86UgYJ0xezSuduTdVkadsgNVItSlKvHfD5Cgb+foVc3veyik QsIGuoZ9kfbcI5+zL+NfMQso08ym1mxGFEUfRW8O3i0n5Jdh3jIYq3qOjUiOuP6Awba4 DjtXMFOFdZuX1xBOpGS4QHy0RktO9N1zNzVrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=HFt1/TsR8+hPj/hMYroULBrvlABrAW8lsgdOIuJwU+0=; b=EBPVPBjkGSXSclWNS0b91684e4zQa2mO/RCpyfCHvT5EnHDk0CItq9N89QUD1qJG3P 5xi4YFUzrV4EBIgnbGvbn7HE2xHaVF4XsvpPzxkjc1ixiJb7vocFAzJTd+n22Mr5aT+7 TN3QPmKiQ45L1LV25PN8ZgFtimRYa1z/kk/EYo1PVPQ2by9RwOwRLt7wFYAWPqKjxtqC hxII0xUmLlUAmhr9rgATOT3BTh/tH15CDFwLodThW+suws4EFYcEgZqYKHrBr7KdBzAI UHIEBVJodcbLOlZzKb0aNEUaQRIzedRXJ5+yyvkCrjLu78vwk6QVwHZaW1EKhTCZZQaB lFlA== X-Received: by 10.224.39.146 with SMTP id g18mr1105944qae.31.1365240513697; Sat, 06 Apr 2013 02:28:33 -0700 (PDT) References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130403151735.GA20820@nic.fr> <20130403163826.GA46759@isc.org> <76E16FA9-84E0-4091-9ECA-5DB0A5BCA90A@dotat.at> <8811862356902250422@unknownmsgid> From: Joe Abley Mime-Version: 1.0 (1.0) In-Reply-To: Date: Sat, 6 Apr 2013 17:28:29 +0800 Message-ID: <2025094731617877595@unknownmsgid> To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmj9GPFDU651g0mFgiAADBFsRBDQa+UkGY8ctRdORg0y5SNE1aLGXO8PXduZvYWxjV9MyY2 Cc: Evan Hunt , "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 09:28:35 -0000 Hi Tony, The intention was that those distributing code that relies upon retrieval of an authentic trust anchor would make arrangements with ICANN to sign trusted copies of the relevant objects themselves and have those signatures published alongside the ICANN-generated signatures. So, ISC could use the same PGP key as they use to sign BIND9 distributions, Apple could use a key derived from their code-signing CA, etc. In this way users could have the same trust in the retrieved trust anchor as they do in the software that has retrieved it. We have not had significant interest from vendors in developing this approach, but we remain interested. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-04-06, at 17:22, Tony Finch wrote: > On 6 Apr 2013, at 10:04, Joe Abley wrote: >> On 2013-04-06, at 16:55, Tony Finch wrote: >>> >>> Validator vendors have to provide an out-of-band trust anchor update me= chanism to cope with this. It needs to be coded and included in long-term s= upport releases of validators and operating systems before rollover, I thin= k. >> >> draft-jabley-dnsop-validator-bootstrap. > > Still needs implementation. > > My point about trustworthiness is that there is (as far as I know) no doc= umentation of how the private keys are managed for the certificates / signa= tures on the trust anchor files, which rather undermines the elaborate root= KSK management. I am also worried about being vulnerable to a screwup by a= ny number of CAs; it would be good to pin the list of CA certs that might b= e used to verify the DNS trust anchor signatures. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ From Ralf.Weber@nominum.com Sat Apr 6 02:32:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC3321F8B65 for ; Sat, 6 Apr 2013 02:32:43 -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 LCgfEDhRMGzn for ; Sat, 6 Apr 2013 02:32:42 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58721F8B45 for ; Sat, 6 Apr 2013 02:32:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUV/ruqFstVWlcBhGQFUFTZGY5bVpYh/4@postini.com; Sat, 06 Apr 2013 02:32:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EE9EF1B8724 for ; Sat, 6 Apr 2013 02:32:41 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E1CF319005D; Sat, 6 Apr 2013 02:32:41 -0700 (PDT) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sat, 6 Apr 2013 02:32:41 -0700 From: Ralf Weber To: Tony Finch Thread-Topic: [DNSOP] public consultation on root zone KSK rollover Thread-Index: AQHOMqmvnFraqv2QjkScyH/h8dxNcQ== Date: Sat, 6 Apr 2013 09:32:41 +0000 Message-ID: <4359B40FE8E82C4BA840D73427B8A45875C60E94@mbx-01.win.nominum.com> References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <43A8B5EA-7C4A-4C53-8479-075C85428EE4@dotat.at> In-Reply-To: <43A8B5EA-7C4A-4C53-8479-075C85428EE4@dotat.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <115A9955BE64CD40ACE597217BA637AB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org WG" , Paul Wouters , Paul Hoffman , Joe Abley Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 09:32:43 -0000 Moin! On 06.04.2013, at 11:04, Tony Finch wrote: > On 3 Apr 2013, at 16:11, Paul Wouters wrote: >=20 >> It's the vendors of equipment supporting DNSSEC that have >> the real issues. If they shipped with a root anchor, and their stuff >> is offline for 5 years and turned on, their DNS will be broken and 5011 >> isn't going to be useful to them..... >=20 > The real problem occurs when the latest release of the validator software= was published before the rollover, and you install it after the rollover. = It is perfectly reasonable to install software that is a few months old. I don't think that this is the real problem. The real problem is when a val= idator has a history of 5011 keys and gets shut down for a year or a couple= of months while the root KSK rolls. Initially it might be better for validators instead of being shipped with a= Key to follow draft-jabley-dnssec-trust-anchor to get the initial root key= . There are some implementations out there that already do this. I think it might be good to extend draft-jabley-dnsop-validator-bootstrap t= o also cover problems introduced by root KSK rollover in order to give peop= le guidance in case their bootstrap process is stuck. I'll also add these comments to the ICANN root key roll consultation page l= ater (just returned from vacation). So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From fanf2@hermes.cam.ac.uk Sat Apr 6 02:44:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0741321F8D8F for ; Sat, 6 Apr 2013 02:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.591 X-Spam-Level: X-Spam-Status: No, score=-5.591 tagged_above=-999 required=5 tests=[AWL=1.008, 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 aCWZ07NkDsPI for ; Sat, 6 Apr 2013 02:44:38 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0EA21F8D86 for ; Sat, 6 Apr 2013 02:44:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from 29.1.120.78.rev.sfr.net ([78.120.1.29]:53046 helo=[192.168.1.66]) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1UOPfp-0005j9-pw (Exim 4.72) (return-path ); Sat, 06 Apr 2013 10:44:37 +0100 References: <87B5FB9E-755D-4E75-A54E-7A17B6AAF21A@hopcount.ca> <8D361F63-C433-4B11-BC26-37D1F550D463@vpnc.org> <20130403151735.GA20820@nic.fr> <20130403163826.GA46759@isc.org> <76E16FA9-84E0-4091-9ECA-5DB0A5BCA90A@dotat.at> <8811862356902250422@unknownmsgid> <2025094731617877595@unknownmsgid> Mime-Version: 1.0 (1.0) In-Reply-To: <2025094731617877595@unknownmsgid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <09B8E2C6-EB5C-40B6-A90A-D9F374AF67D0@dotat.at> X-Mailer: iPhone Mail (10B144) From: Tony Finch Date: Sat, 6 Apr 2013 10:44:32 +0100 To: Joe Abley Sender: Tony Finch Cc: Evan Hunt , "dnsop@ietf.org WG" , Paul Hoffman Subject: Re: [DNSOP] public consultation on root zone KSK rollover X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 09:44:39 -0000 On 6 Apr 2013, at 10:28, Joe Abley wrote: > The intention was that those distributing code that relies upon > retrieval of an authentic trust anchor would make arrangements with > ICANN to sign trusted copies of the relevant objects themselves and > have those signatures published alongside the ICANN-generated > signatures. Sounds sensible to me. Really must press forward with implementing this well before the rollover. Tony. -- f.anthony.n.finch http://dotat.at/ From bortzmeyer@nic.fr Fri Apr 12 07:55:45 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823A321F8C69 for ; Fri, 12 Apr 2013 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.949 X-Spam-Level: X-Spam-Status: No, score=-99.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.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 zZaHnZlc89dH for ; Fri, 12 Apr 2013 07:55:44 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id C10B621F8C0C for ; Fri, 12 Apr 2013 07:55:44 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C37FC280B26; Fri, 12 Apr 2013 16:55:08 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id BEEA2280B25; Fri, 12 Apr 2013 16:55:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay1.nic.fr (Postfix) with ESMTP id BC8354C007E; Fri, 12 Apr 2013 16:54:38 +0200 (CEST) Date: Fri, 12 Apr 2013 16:54:38 +0200 From: Stephane Bortzmeyer To: Joe Abley Message-ID: <20130412145438.GA7635@nic.fr> References: <20130325192943.26036.53057.idtracker@ietfa.amsl.com> <7F1CDC8A-9007-454E-BFA3-FFD5E5E1C729@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F1CDC8A-9007-454E-BFA3-FFD5E5E1C729@hopcount.ca> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-anycast-mapping-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:55:45 -0000 On Mon, Mar 25, 2013 at 03:40:55PM -0400, Joe Abley wrote a message of 66 lines which said: > However, I am of course interested in accuracy and clarity in the > text. If you have a few spare minutes and don't mind giving me a > review, I'd appreciate it. I believe it is useful, I liked the ideas (specially IDENTITY.L.ROOT-SERVERS.ORG) and I would like to see more of such documents for critical services. On ther other hand, I'm not sure a RFC is the best way to publish them. May be somewhere under ? Bug report: IDENTITY.L.ROOT-SERVERS.ORG does not work from my office: % ping IDENTITY.L.ROOT-SERVERS.ORG PING IDENTITY.L.ROOT-SERVERS.ORG (193.51.11.57) 56(84) bytes of data. 64 bytes from 193.51.11.57: icmp_req=1 ttl=59 time=203 ms ... % dig -x 193.51.11.57 ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -x 193.51.11.57 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3324 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;57.11.51.193.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 11.51.193.in-addr.arpa. 86380 IN SOA ns1.renater.fr. hostmaster.renater.fr. 2010052001 28800 7200 604800 86400 ;; Query time: 56 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Apr 12 16:50:29 2013 ;; MSG SIZE rcvd: 115 From jabley@hopcount.ca Fri Apr 12 14:11:16 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F7721F874E for ; Fri, 12 Apr 2013 14:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, MIME_QP_LONG_LINE=1.396, 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 wmFTb-ofCYzD for ; Fri, 12 Apr 2013 14:11:05 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D78CC21F859C for ; Fri, 12 Apr 2013 14:11:04 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id i20so3544qad.17 for ; Fri, 12 Apr 2013 14:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=ZSIKURt9L3FOJMquQoHpiDEX4XWptW6KMP7qLwNGKLg=; b=VIiZoHnesCjrZGyKFfln8Kam61mEtTHSuPTl8hgq3SQv9xsasmhMyXwQK2SfS02FB/ u9aowSWghzIgpXPkOzQ8x+l0YgrsBkWe0WDSOR63PmIzub2HaA38Tt6NCj9kCmM7pm48 Y7/cnG396j7kPVX5u7KGK0YJVA4VZNdXSI3xU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=ZSIKURt9L3FOJMquQoHpiDEX4XWptW6KMP7qLwNGKLg=; b=NQPiXZ580vShUdbtmbmGIyLSQEDxo8DB2D5lbmv0FKl7/mnefN4AOKthiHsItGoTPu 8b0EBRdFqg1t/ykDCGm3KDIlgyNtc4/NdJPpAz82E31CcwAE8FSjf/iBDvzEKWVtKv9x WNvrtdtphk5xZhBE48VEp8xqA0PFgeuYtEwDBNqMRfDxIVjDHLivR/E/7IwPYi66kZGL kk9C45yQUUSmzJPOO1jPwMxkP4hd4EnRenethxKzzdOLQ3Xi4P01hFf8R4pKsvUKiF4h AH8bila8iBhKEkWlmUHwj+p3AprnVmNEvUdw0vat8iwFiN3hAbTiS1Qi+/MSBCwweb89 9evw== X-Received: by 10.229.82.136 with SMTP id b8mr1811907qcl.20.1365801064239; Fri, 12 Apr 2013 14:11:04 -0700 (PDT) Received: from [10.168.197.149] (out-pq-149.wireless.telus.com. [216.218.29.149]) by mx.google.com with ESMTPS id m8sm16320209qav.8.2013.04.12.14.11.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 14:11:03 -0700 (PDT) References: <20130325192943.26036.53057.idtracker@ietfa.amsl.com> <7F1CDC8A-9007-454E-BFA3-FFD5E5E1C729@hopcount.ca> <20130412145438.GA7635@nic.fr> Mime-Version: 1.0 (1.0) In-Reply-To: <20130412145438.GA7635@nic.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9F303109-8621-4BCA-A020-A5E977E59312@hopcount.ca> X-Mailer: iPad Mail (10B329) From: Joe Abley Date: Fri, 12 Apr 2013 17:11:01 -0400 To: Stephane Bortzmeyer X-Gm-Message-State: ALoCoQljNKIqo2yDYJCDZWhLkxdjZ+CI4vNQ9D7BHyrvCVF0fLDgeF7VQe/v84r1d9wHXO1ogwvQ Cc: "dnsop@ietf.org WG" Subject: Re: [DNSOP] New Version Notification for draft-jabley-dnsop-anycast-mapping-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 21:11:16 -0000 On 2013-04-12, at 10:54, Stephane Bortzmeyer wrote: > On Mon, Mar 25, 2013 at 03:40:55PM -0400, > Joe Abley wrote=20 > a message of 66 lines which said: >=20 >> However, I am of course interested in accuracy and clarity in the >> text. If you have a few spare minutes and don't mind giving me a >> review, I'd appreciate it. >=20 > I believe it is useful, I liked the ideas (specially > IDENTITY.L.ROOT-SERVERS.ORG) and I would like to see more of such > documents for critical services. Thanks! > On ther other hand, I'm not sure a RFC is the best way to publish > them. May be somewhere under ? That's certainly an option. The motivation for using the RFC series was part= ly to provide a stable, citation-friendly reference for other future work an= d partly to record these aspects of the L-Root service for the historical re= cord. The document is currently with the Independent Stream Editor who is looking f= or reviewers. I'm not especially familiar with that process, but it seems po= ssible that volunteering to review would be appreciated (since you've alread= y taken the time to read it). > Bug report: IDENTITY.L.ROOT-SERVERS.ORG does not work from my office: >=20 > % ping IDENTITY.L.ROOT-SERVERS.ORG > PING IDENTITY.L.ROOT-SERVERS.ORG (193.51.11.57) 56(84) bytes of data. > 64 bytes from 193.51.11.57: icmp_req=3D1 ttl=3D59 time=3D203 ms > ... So, this demonstrates that the IDENTITY.L.ROOT-SERVERS.ORG name is actually w= orking fine for you (you looked for an A, and you got one). Geo-loc informat= ion is available by looking for a TXT. > % dig -x 193.51.11.57 >=20 > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> -x 193.51.11.57 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3324 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;57.11.51.193.in-addr.arpa. IN PTR >=20 > ;; AUTHORITY SECTION: > 11.51.193.in-addr.arpa. 86380 IN SOA ns1.renater.fr. hostmaste= r.renater.fr. 2010052001 28800 7200 604800 86400 >=20 > ;; Query time: 56 msec > ;; SERVER: ::1#53(::1) > ;; WHEN: Fri Apr 12 16:50:29 2013 > ;; MSG SIZE rcvd: 115 This seems to demonstrate that the particular L-Root host network you see fr= om there does not have their reverse DNS set up for the address they assigne= d us. We'll follow up on that because we think reverse DNS is useful and goo= d, but that's a separate issue from the functionality of the IDENTITY.L.ROOT= -SERVERS.ORG name. Joe= From joelja@bogus.com Sun Apr 14 09:08:36 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D95721F851C for ; Sun, 14 Apr 2013 09:08:36 -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 tAs4iAQy3vp5 for ; Sun, 14 Apr 2013 09:08:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AA7AE21F85B3 for ; Sun, 14 Apr 2013 09:08:31 -0700 (PDT) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r3EG8Um2040816 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 14 Apr 2013 16:08:31 GMT (envelope-from joelja@bogus.com) Message-ID: <516AD478.8070503@bogus.com> Date: Sun, 14 Apr 2013 09:08:24 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: dnsop@ietf.org References: <516AD188.1020408@bogus.com> In-Reply-To: <516AD188.1020408@bogus.com> X-Forwarded-Message-Id: <516AD188.1020408@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 14 Apr 2013 16:08:31 +0000 (UTC) Subject: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 16:08:36 -0000 -------- Original Message -------- Subject: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... Date: Sun, 14 Apr 2013 08:55:52 -0700 From: joel jaeggli To: dnsext@ietf.org, dnsops@ietf.org CC: draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org I've been asked to take this document on as AD sponsored individual submission. http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 If there's anyone who has strenuous objections to that, please let me know. joel From joelja@bogus.com Mon Apr 15 09:03:42 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F8121F8EDA; Mon, 15 Apr 2013 09:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 zJrdUUrlUlbU; Mon, 15 Apr 2013 09:03:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7350421F84CE; Mon, 15 Apr 2013 09:03:41 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r3FG3cHw054141 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 15 Apr 2013 16:03:39 GMT (envelope-from joelja@bogus.com) Message-ID: <516AFED4.5000504@bogus.com> Date: Sun, 14 Apr 2013 12:09:08 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Michael StJohns References: <516AD188.1020408@bogus.com> <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> In-Reply-To: <24BA22EC-7C7F-4698-8EC1-A6A350986A50@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 15 Apr 2013 16:03:39 +0000 (UTC) Cc: "dnsop@ietf.org" , "dnsext@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Subject: Re: [DNSOP] [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:03:42 -0000 On 4/14/13 9:40 AM, Michael StJohns wrote: > What exactly is the purpose for this document? Specifically, please > describe the concept of operations for the use of this record. The rational described on this list a month ago was as follows: -------- Original Message -------- Subject: [dnsext] Fwd: New Version Notification for draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt Date: Tue, 19 Mar 2013 10:33:04 -0400 From: Joe Abley To: dnsext@ietf.org Group Hi all, During a conversation about an attempt to stuff IP and subscriber MAC addresses into the DNS (something that is happening operationally in Canada, related to wholesale cable internet service) I noticed that there is currently no clean way to represent ethernet MAC addresses. People are either using TXT records, or encoding MAC addresses into PTR RDATA, and it's all a bit messy. Assuming that this is not the last time that someone will find a reason to encode layer-2 addresses in the DNS, I thought it worthwhile to define a cleaner option. The draft referenced below defines two new RRTypes, EUI48 (for EUI-48 addresses, which is what prompted this line of thinking) and EUI64 (for EUI-64 addresses, since it seems silly to accommodate one without the other). The wire format is pretty trivial (network byte order, simple octet string), the RRTypes chosen are unremarkable (not sure what else you'd call an EUI-48 address RRType than EUI48) and the presentation format should be familiar. The examples given use the ethernet address of the wireless adapter on my laptop and its EUI-64 mapping, for lack of any documentation OUI that I could find. The IEEE references are consistent with the references for EUI-64 in IPv6, e.g. in RFC 4291. The expert review template for the RRType application is included as an appendix. In the event that this proposal doesn't meet with projectile heartburn, I would hope that this could be adopted, discussed, refined and last-called before the demise of dnsext. Alternatively, assuming again that the expert review raises no concerns and code points are assigned, it could proceed as an individual-track submission. Comments welcome. Joe > > Mapping a name directly to a MAC address seems somewhat problematic > and perhaps even dangerous to consistency. > > I understand storing things in the DNS system is attractive, but > adapting it to store L2 data may be going a bit too far past it's > designed scope, The scope in which such a mapping is useful is clearly fairly limited, I imagine there are provisioning/subscriber managment systems that would adopt such a representation, but I imagine the author has a more specifc example. > I would object to the document absent a clear and convincing > description of why it is needed and what applications will use it. > > Mike > > Sent from my iPad > > On Apr 14, 2013, at 11:55, joel jaeggli wrote: > >> I've been asked to take this document on as AD sponsored individual >> submission. >> >> http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 >> >> >> If there's anyone who has strenuous objections to that, please let me know. >> >> joel _______________________________________________ dnsext mailing >> list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > From ed.lewis@neustar.biz Mon Apr 15 10:14:07 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663D821F9458 for ; Mon, 15 Apr 2013 10:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JJwv8BuvOXXh for ; Mon, 15 Apr 2013 10:14:06 -0700 (PDT) Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) by ietfa.amsl.com (Postfix) with ESMTP id C56E021F93DC for ; Mon, 15 Apr 2013 10:14:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4B83A1B015C; Mon, 15 Apr 2013 13:14:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 0D35E1B016E; Mon, 15 Apr 2013 13:14:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_097C4720-8D43-40D5-A276-29EB0DBE718B" From: Edward Lewis In-Reply-To: <516AD478.8070503@bogus.com> Date: Mon, 15 Apr 2013 13:14:05 -0400 Message-Id: References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:14:07 -0000 --Apple-Mail=_097C4720-8D43-40D5-A276-29EB0DBE718B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have no problem with this in spirit. But I always wonder why the = presentation formats, as in section 3.2 and 4.2, have MUST concerning = how the record is "written." I've never considered the presentation = format to be subject to a standard...I realize that's just my opinion, = but the on-the-wire format is what is subject to interoperability = concerns. The document can have the MUSTs but I'd prefer SHOULDs. It's right that = there's only one way these addresses ever get written, so the MUST seems = logical, OTOH, it just seems over the top to demand it be written one = way or another. I certainly understand it is INTENDED to be written as = documented, but is it a sin if I implement something else? (How would = an alternate form hinder interoperability.) Apparently I am a little cranky today. On Apr 14, 2013, at 12:08, joel jaeggli wrote: > -------- Original Message -------- > Subject: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored = individual sumission... > Date: Sun, 14 Apr 2013 08:55:52 -0700 > From: joel jaeggli > To: dnsext@ietf.org, dnsops@ietf.org > CC: draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org >=20 >=20 >=20 > I've been asked to take this document on as AD sponsored individual > submission. >=20 > http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 >=20 > If there's anyone who has strenuous objections to that, please let me = know. >=20 > joel >=20 >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_097C4720-8D43-40D5-A276-29EB0DBE718B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The document can = have the MUSTs but I'd prefer SHOULDs.  It's right that there's = only one way these addresses ever get written, so the MUST seems = logical, OTOH, it just seems over the top to demand it be written one = way or another.  I certainly understand it is INTENDED to be = written as documented, but is it a sin if I implement something else? =  (How would an alternate form hinder = interoperability.)

Apparently I am a little = cranky today.

On Apr 14, 2013, at 12:08, joel jaeggli = wrote:

-------- Original Message --------
Subject: = draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored = individual sumission...
Date: Sun, 14 Apr 2013 08:55:52 = -0700
From: = joel jaeggli <joelja@bogus.com>
To: dnsext@ietf.org, dnsops@ietf.org
CC: dra= ft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org



I'v= e been asked to take this document on as AD sponsored = individual
submission.

http://tools.ietf.org/html/draft-jabley-d= nsext-eui48-eui64-rrtypes-02

If there's anyone who has strenuous = objections to that, please let me = know.

joel



_________________________________________= ______
DNSOP mailing = list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
<= /div>

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_097C4720-8D43-40D5-A276-29EB0DBE718B-- From jabley@hopcount.ca Mon Apr 15 10:32:18 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27E821F9600 for ; Mon, 15 Apr 2013 10:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.264 X-Spam-Level: X-Spam-Status: No, score=-97.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, 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 mwITWCyyPptB for ; Mon, 15 Apr 2013 10:32:17 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7285F21F95EC for ; Mon, 15 Apr 2013 10:32:17 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id e16so4597462iaa.34 for ; Mon, 15 Apr 2013 10:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=i18qn9qPv5wT8vQ3+YxaIf+X9xgYLXCvT+jhI7vl6/Q=; b=aboEsUOGv7r5VkGxkvEFhacHR3osFHHrHCYJb5rLXd3VzOCfgG4qCF1CbKOH+M9f0F hizUGyXtoYQrvqLWkcJ+6XNMlzPQTQusx0Kng33FG4KPZyX1/ZWwWxiryYFgAfLbEExq UWNxT125tYo83e3MzWJU4aTODs8ETcSdwqpiY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=i18qn9qPv5wT8vQ3+YxaIf+X9xgYLXCvT+jhI7vl6/Q=; b=I6KHaK3YXJmInRdhlyumVdJrJN8FscS40S4El6obOsPDGUkC07XUrGVt7hMzIEwXrG JUlk9u0ct956Jc7EJLk59q2VmRNPaJP/0WJAPPNnQGkIJk5UG9Wnp2l/XUKenJItTtqr CSk47dQhgUiZ1CVxsKZodMZjpNqXiY2HVq0tQT0EECw/o08Kf/FbMLXnla+qAsIW2V45 mjzmGDIIklKgqa7zf0xnGImKeMY1mQV4PLltJ0nHsRE1zwYW/WHAHHg+JvEUbejccsA8 Lwo/4qrHCuoFZPRFisEwFPWrBClOlOL0tMT2GU648sTuzwUAujc8Jz7K58/HhAHcu801 4Sfg== X-Received: by 10.50.112.100 with SMTP id ip4mr6069464igb.87.1366047136956; Mon, 15 Apr 2013 10:32:16 -0700 (PDT) Received: from [10.169.22.36] (out-on-164.wireless.telus.com. [207.219.69.164]) by mx.google.com with ESMTPS id xf4sm11750493igb.8.2013.04.15.10.32.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 10:32:16 -0700 (PDT) References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-DDC76921-1CA0-4547-B625-DC1F718CB7D2 Message-Id: <8AEB7A7F-28B6-4C1B-8016-3F4576E4A742@hopcount.ca> X-Mailer: iPad Mail (10B329) From: Joe Abley Date: Mon, 15 Apr 2013 13:32:17 -0400 To: Edward Lewis X-Gm-Message-State: ALoCoQmj59l5G0NVhTSKgRgElt9xP4fPJ5XmY2cKmSyrlR84XW6O1T8Vw0PqlJmiKBchtwoV5R9s Cc: IETF DNSOP WG , Edward Lewis Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:32:18 -0000 --Apple-Mail-DDC76921-1CA0-4547-B625-DC1F718CB7D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Ed, On 2013-04-15, at 13:14, Edward Lewis wrote: > I have no problem with this in spirit. But I always wonder why the presen= tation formats, as in section 3.2 and 4.2, have MUST concerning how the reco= rd is "written." I've never considered the presentation format to be subjec= t to a standard...I realize that's just my opinion, but the on-the-wire form= at is what is subject to interoperability concerns. I think that's valid. My thinking when I wrote the draft is that there are two areas where interop= is important: (a) on the wire, where incompatibility would simply break eve= rything, and (b) in the canonical zone file format, where incompatibility wo= uld annoy operators (who might have to generate two different zones to be se= rved by two different nameservers, for example). The first draft specified MUSTs with aa:bb:cc:dd:ee style notation, since th= at's what I see most often on network gear and in Unix. I was subsequently s= hown an IEEE document that included aa-bb-cc-dd-ee as a canonical representa= tion, so I changed it. > The document can have the MUSTs but I'd prefer SHOULDs. It's right that t= here's only one way these addresses ever get written, so the MUST seems logi= cal, OTOH, it just seems over the top to demand it be written one way or ano= ther. I certainly understand it is INTENDED to be written as documented, bu= t is it a sin if I implement something else? (How would an alternate form h= inder interoperability.) I think a SHOULD is too weak though. I spend a lot of time parsing the outpu= t from tools that decode DNS messages, and if different tools used different= presentation formats for the same wire data it would make my life hard. I could specify that both formats were permitted on input (parse zone file) o= r output (generate zone file). I certainly agree that the canonical IEEE for= mat is not the most common, at least with the systems I most frequently use.= > Apparently I am a little cranky today. One too many Beijing hamburgers. Joe= --Apple-Mail-DDC76921-1CA0-4547-B625-DC1F718CB7D2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Ed,
=

On 2013-04-15, at 13:14, Edward Lewis <ed.lewis@neustar.biz> wrote:

I have no problem with this in spirit.  = But I always wonder why the presentation formats, as in section 3.2 and 4.2,= have MUST concerning how the record is "written."  I've never consider= ed the presentation format to be subject to a standard...I realize that's ju= st my opinion, but the on-the-wire format is what is subject to interoperabi= lity concerns.

I think that's va= lid.

My thinking when I wrote the draft is that the= re are two areas where interop is important: (a) on the wire, where incompat= ibility would simply break everything, and (b) in the canonical zone file fo= rmat, where incompatibility would annoy operators (who might have to generat= e two different zones to be served by two different nameservers, for example= ).

The first draft specified MUSTs with aa:bb:cc:dd= :ee style notation, since that's what I see most often on network gear and i= n Unix. I was subsequently shown an IEEE document that included aa-bb-cc-dd-= ee as a canonical representation, so I changed it.

The document can have the MUSTs but I'd prefer SHO= ULDs.  It's right that there's only one way these addresses ever get wr= itten, so the MUST seems logical, OTOH, it just seems over the top to demand= it be written one way or another.  I certainly understand it is INTEND= ED to be written as documented, but is it a sin if I implement something els= e?  (How would an alternate form hinder interoperability.)

I think= a SHOULD is too weak though. I spend a lot of time parsing the output from t= ools that decode DNS messages, and if different tools used different present= ation formats for the same wire data it would make my life hard.

<= div style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webki= t-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition= -frame-color: rgba(77, 128, 180, 0.230469); ">I could specify that both form= ats were permitted on input (parse zone file) or output (generate zone file)= . I certainly agree that the canonical IEEE format is not the most common, a= t least with the systems I most frequently use.

= Apparently I am a little cranky today.

One too many Beijing hamburgers.


<= div>Joe
= --Apple-Mail-DDC76921-1CA0-4547-B625-DC1F718CB7D2-- From paul.hoffman@vpnc.org Mon Apr 15 11:00:56 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CFE21F95F7 for ; Mon, 15 Apr 2013 11:00:56 -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 f46BaOGSCqVS for ; Mon, 15 Apr 2013 11:00: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 6599721F9588 for ; Mon, 15 Apr 2013 11:00:56 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3FI0tAB021075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Apr 2013 11:00:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Mon, 15 Apr 2013 11:00:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A461723-1199-4C3C-B2E0-1955C91A76E2@vpnc.org> References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> To: Edward Lewis X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG Subject: [DNSOP] Presentation formats for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:00:56 -0000 On Apr 15, 2013, at 10:14 AM, Edward Lewis wrote: > I have no problem with this in spirit. But I always wonder why the = presentation formats, as in section 3.2 and 4.2, have MUST concerning = how the record is "written." I've never considered the presentation = format to be subject to a standard...I realize that's just my opinion, = but the on-the-wire format is what is subject to interoperability = concerns. This has come up before, and there are indeed interoperability issues = with presentation formats. Developers will use examples they find in the = RFC and on the Internet to create encoders and parsers. If there is an = agreed-to presentation format, the likelihood of wire interoperability = goes way up. > The document can have the MUSTs but I'd prefer SHOULDs. =20 A "SHOULD" is a "MUST except for these reasons". What would the reasons = be for using a different presentation format? > It's right that there's only one way these addresses ever get written, = so the MUST seems logical, OTOH, it just seems over the top to demand it = be written one way or another. I certainly understand it is INTENDED to = be written as documented, but is it a sin if I implement something else? = (How would an alternate form hinder interoperability.) >=20 > Apparently I am a little cranky today. ...and haven't re-read RFC 2119 in a while. There is no mention of = "sin". --Paul Hoffman= From ed.lewis@neustar.biz Mon Apr 15 11:08:24 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A12321F86E4 for ; Mon, 15 Apr 2013 11:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3olrKpTiODxD for ; Mon, 15 Apr 2013 11:08:24 -0700 (PDT) Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) by ietfa.amsl.com (Postfix) with ESMTP id 1A50B21F9058 for ; Mon, 15 Apr 2013 11:08:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B23111B00B7; Mon, 15 Apr 2013 14:08:22 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 71B111B01BE; Mon, 15 Apr 2013 14:08:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C5A36250-A587-45F2-A053-0D3AF221FABA" From: Edward Lewis In-Reply-To: <8AEB7A7F-28B6-4C1B-8016-3F4576E4A742@hopcount.ca> Date: Mon, 15 Apr 2013 14:08:21 -0400 Message-Id: <9D0566A3-02F9-4CBE-9089-EC56BB33FA2F@neustar.biz> References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <8AEB7A7F-28B6-4C1B-8016-3F4576E4A742@hopcount.ca> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:08:24 -0000 --Apple-Mail=_C5A36250-A587-45F2-A053-0D3AF221FABA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 15, 2013, at 13:32, Joe Abley wrote: > I think a SHOULD is too weak though. I spend a lot of time parsing the = output from tools that decode DNS messages, and if different tools used = different presentation formats for the same wire data it would make my = life hard. But are the log writers subject to the rules and regulations in an RFC? = Sigh. Anyway, I get this way when I try to read an RFC as a = specification document. > One too many Beijing hamburgers. It's shameful enough to have to admit to ordering a hamburger in = Beijing, still the punishment was far more than deserved. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_C5A36250-A587-45F2-A053-0D3AF221FABA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = think a SHOULD is too weak though. I spend a lot of time parsing the = output from tools that decode DNS messages, and if different tools used = different presentation formats for the same wire data it would make my = life hard.

But are the log = writers subject to the rules and regulations in an RFC?  Sigh. =  Anyway, I get this way when I try to read an RFC as a = specification document.

One too many Beijing = hamburgers.

It's shameful enough = to have to admit to ordering a hamburger in Beijing, still the = punishment was far more than deserved.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_C5A36250-A587-45F2-A053-0D3AF221FABA-- From jabley@hopcount.ca Mon Apr 15 11:15:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6664E21F9632 for ; Mon, 15 Apr 2013 11:15:43 -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 wc47TISQO7F9 for ; Mon, 15 Apr 2013 11:15:42 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 956A021F9631 for ; Mon, 15 Apr 2013 11:15:42 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id o25so1824156iad.33 for ; Mon, 15 Apr 2013 11:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=oxsZjKxNpSSTibQOk+sLj8YWyj4f8pfeGgV18HQFPY8=; b=AIgYd4IkjdX2G1qhUHgwG4f3154J2kyGiDqVuP+qe7rf8TZAIZeQGA0S65AkseRpIs dBaU6B7shQx2051tm6BmAfW/WVPWQ4G/gC761XODa+184P+gmgP3/SuhpOgiXJ8ir7ul G9yo4OTrc1GDVLd6bVywjYpPuiRwxAvvQDb00= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=oxsZjKxNpSSTibQOk+sLj8YWyj4f8pfeGgV18HQFPY8=; b=Z1nKdDkvflUBDXvbIi7wmoshoxNXq6HmO5Z9efCvB2KKFaz2LQ7hGDxnPsjxLTdVbW WrfnBIWWZA4YFujgakmWBVASAqOvWTNqsSrx+8VCJDasTEXRFNg2ntnBPoluvPKoABb3 5+MfTT0CDDVn9myeF3Xllu7LpwHd18YdSFLy8L0BHXd69QZ2MQvVqYCVP+syM9RUe2bF jzn2XXPAAnYY+UJo5qqlwmCGb1rZm4+YIc0j6LvTciFNl4XyLsuIvjQGrO6LUS0442lh Gm1fOMyP26YHpGapVDBU7L/pcuV0qKyvXuM0bcODG5jsmDVVrtcmj70YRC/TQ9dUKM7t 9Vww== X-Received: by 10.50.135.74 with SMTP id pq10mr5608230igb.46.1366049742163; Mon, 15 Apr 2013 11:15:42 -0700 (PDT) Received: from [10.23.45.55] (nat.teksavvy.com. [206.248.154.94]) by mx.google.com with ESMTPS id ip2sm11938348igc.5.2013.04.15.11.15.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 11:15:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <9D0566A3-02F9-4CBE-9089-EC56BB33FA2F@neustar.biz> Date: Mon, 15 Apr 2013 14:15:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <8AEB7A7F-28B6-4C1B-8016-3F4576E4A742@hopcount.ca> <9D0566A3-02F9-4CBE-9089-EC56BB33FA2F@neustar.biz> To: Edward Lewis X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQl7BmqfSQKdN58o1ZMBGAW5ljnfhz2PiMdodw6U4s7K/QjxtTDumya0hwdMqFqRUywBfYGe Cc: IETF DNSOP WG Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:15:43 -0000 On 2013-04-15, at 14:08, Edward Lewis wrote: > On Apr 15, 2013, at 13:32, Joe Abley wrote: >=20 >> I think a SHOULD is too weak though. I spend a lot of time parsing = the output from tools that decode DNS messages, and if different tools = used different presentation formats for the same wire data it would make = my life hard. >=20 > But are the log writers subject to the rules and regulations in an = RFC? Well, I was talking about zone files and resource records (e.g. things = you load into knot/nsd/bind9, things you receive back from kdig/dig), = not log files. In my experience people who write logging code in nameservers are = subject to nobody, least of all their users. That's probably harsh. But = fair. > Sigh. Anyway, I get this way when I try to read an RFC as a = specification document. Try reading this specification document as an RFC :-) Joe From ed.lewis@neustar.biz Mon Apr 15 11:54:04 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8A621F84B5 for ; Mon, 15 Apr 2013 11:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.868 X-Spam-Level: X-Spam-Status: No, score=-101.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 9LaTeGGF6RwH for ; Mon, 15 Apr 2013 11:54:04 -0700 (PDT) Received: from smtp155.dfw.emailsrvr.com (smtp155.dfw.emailsrvr.com [67.192.241.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0296221F9623 for ; Mon, 15 Apr 2013 11:54:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 8931E2D03D7; Mon, 15 Apr 2013 14:54:02 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id C86032D0434; Mon, 15 Apr 2013 14:54:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FD940BC1-F4A5-41FF-894B-DA837436C652" From: Edward Lewis In-Reply-To: Date: Mon, 15 Apr 2013 14:54:01 -0400 Message-Id: <3A911C74-A4FC-40A1-A83C-FDFD55F194DF@neustar.biz> References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <8AEB7A7F-28B6-4C1B-8016-3F4576E4A742@hopcount.ca> <9D0566A3-02F9-4CBE-9089-EC56BB33FA2F@neustar.biz> To: Joe Abley , IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:54:05 -0000 --Apple-Mail=_FD940BC1-F4A5-41FF-894B-DA837436C652 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 15, 2013, at 14:15, Joe Abley wrote: > Well, I was talking about zone files and resource records (e.g. things = you load into knot/nsd/bind9, things you receive back from kdig/dig), = not log files. It's just more code. ;) > Try reading this specification document as an RFC :-) Or I could have another hamburger. Really, it's no big deal. (The presentation format that is, digesting = poorly cooked ground beef is a big deal.) Ahh - here we go with food on an IETF list. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_FD940BC1-F4A5-41FF-894B-DA837436C652 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Well, I was talking about = zone files and resource records (e.g. things you load into = knot/nsd/bind9, things you receive back from kdig/dig), not log = files.

It's just more code. = ;)

Try reading this specification = document as an RFC :-)

Or I = could have another hamburger.

Really, it's no big = deal.  (The presentation format that is, digesting poorly cooked = ground beef is a big deal.)

Ahh - here we go = with food on an IETF list.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_FD940BC1-F4A5-41FF-894B-DA837436C652-- From marka@isc.org Mon Apr 15 22:42:59 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4921F93E0 for ; Mon, 15 Apr 2013 22:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt6CoRol3ybg for ; Mon, 15 Apr 2013 22:42:57 -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 B3ADB21F860B for ; Mon, 15 Apr 2013 22:42:50 -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 80BC25F98B1; Tue, 16 Apr 2013 05:42:30 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366090960; bh=C6t1GzI8ovc4WzQCZ5EdnSa4HPjuUPfc63wttwktZsA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=XVaSvQXobf1R/Aq48w6PDoDK+qBPuUCa5GYCN/jTGHKHqyTQTj6dW/ToZx+dbd+7g Ek8rnjaHD+olXYJ6Negx5NX/aEqII2VCXaC4Ry/tTueggWXFmOKZZb9pNnYDyhjtoU 38+wry5p6yKpl2PRHgok7XwqYufsLieAtnq9GY8c= Received: from drugs.dv.isc.org (dsl092-002-166.sfo1.dsl.speakeasy.net [66.92.2.166]) (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 EEC75216C3B; Tue, 16 Apr 2013 05:42:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id C0E2E326C22C; Tue, 16 Apr 2013 15:42:23 +1000 (EST) To: Edward Lewis From: Mark Andrews References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> In-reply-to: Your message of "Mon, 15 Apr 2013 13:14:05 -0400." Date: Tue, 16 Apr 2013 15:42:23 +1000 Message-Id: <20130416054223.C0E2E326C22C@drugs.dv.isc.org> Cc: IETF DNSOP WG Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 05:42:59 -0000 In message , Edward Lewis writes: > I have no problem with this in spirit. But I always wonder why the > presentation formats, as in section 3.2 and 4.2, have MUST concerning how > the record is "written." I've never considered the presentation format > to be subject to a standard...I realize that's just my opinion, but the > on-the-wire format is what is subject to interoperability concerns. It's a MUST because master file format is a interchange standard. RFC 1034 The standard format of master files allows them to be exchanged between hosts (via FTP, mail, or some other mechanism); this facility is useful when an organization wants a domain, but doesn't want to support a name server. The organization can maintain the master files locally using a text editor, transfer them to a foreign host which runs a name server, and then arrange with the system administrator of the name server to get the files loaded. Mark > The document can have the MUSTs but I'd prefer SHOULDs. It's right that > there's only one way these addresses ever get written, so the MUST seems > logical, OTOH, it just seems over the top to demand it be written one way > or another. I certainly understand it is INTENDED to be written as > documented, but is it a sin if I implement something else? (How would an > alternate form hinder interoperability.) > > Apparently I am a little cranky today. > > On Apr 14, 2013, at 12:08, joel jaeggli wrote: > > > -------- Original Message -------- > > Subject: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored > individual sumission... > > Date: Sun, 14 Apr 2013 08:55:52 -0700 > > From: joel jaeggli > > To: dnsext@ietf.org, dnsops@ietf.org > > CC: draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org > > > > > > > > I've been asked to take this document on as AD sponsored individual > > submission. > > > > http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02 > > > > If there's anyone who has strenuous objections to that, please let me > know. > > > > joel > > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > - > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > There are no answers - just tradeoffs, decisions, and responses. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Apr 15 23:25:02 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E938B21F961A for ; Mon, 15 Apr 2013 23:25:01 -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 AnfQPpbAT-Ec for ; Mon, 15 Apr 2013 23:25:01 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3724F21F9617 for ; Mon, 15 Apr 2013 23:25:01 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F1B87C94B6; Tue, 16 Apr 2013 06:24:51 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366093500; bh=oRCJ7msjtFueFfvlgHzPwUv8Zf30HmUl20jO1CrYYUw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=MsUNnjk085jd3nfCFMGgkxX9f7xdkXvS1dKEQtKajmDWYVe0D1owVKRkxAd+62bPX hETGK5bkYtkTi7YYamOhFmvUdfN7ob1M0VE6qWqGhxx2ew3N8iPEFkKMZyd+BEjFZB uB2OiFILtjpY9zqlVyOuLQu8M/3bmVxsnXI/Ti9g= 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.pao1.isc.org (Postfix) with ESMTPS; Tue, 16 Apr 2013 06:24:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (dsl092-002-166.sfo1.dsl.speakeasy.net [66.92.2.166]) (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 AF955216C3B; Tue, 16 Apr 2013 06:24:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7513D326C870; Tue, 16 Apr 2013 16:24:46 +1000 (EST) To: Paul Hoffman From: Mark Andrews References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <2A461723-1199-4C3C-B2E0-1955C91A76E2@vpnc.org> In-reply-to: Your message of "Mon, 15 Apr 2013 11:00:54 -0700." <2A461723-1199-4C3C-B2E0-1955C91A76E2@vpnc.org> Date: Tue, 16 Apr 2013 16:24:46 +1000 Message-Id: <20130416062446.7513D326C870@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IETF DNSOP WG , Edward Lewis Subject: Re: [DNSOP] Presentation formats for DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 06:25:02 -0000 In message <2A461723-1199-4C3C-B2E0-1955C91A76E2@vpnc.org>, Paul Hoffman writes: > On Apr 15, 2013, at 10:14 AM, Edward Lewis wrote: > > > I have no problem with this in spirit. But I always wonder why the > > presentation formats, as in section 3.2 and 4.2, have MUST concer > > ning how the record is "written." I've never considered the presentation > > format to be subject to a standard...I realize that's just my > > opinion, but the on-the-wire format is what is subject to > > interoperability concerns. > > This has come up before, and there are indeed interoperability issues > with presentation formats. Developers will use examples they find > in the RFC and on the Internet to create encoders and parsers. If there > is an agreed-to presentation format, the likelihood of wire in > teroperability goes way up. Web site developers not reading the RFCs has lead to problems entering perfectly valid DS records. > > The document can have the MUSTs but I'd prefer SHOULDs. > > A "SHOULD" is a "MUST except for these reasons". What would the reasons > be for using a different presentation format? > > > It's right that there's only one way these addresses ever get written, > > so the MUST seems logical, OTOH, it just seems over the top to > > demand it be written one way or another. I certainly understand it is > > INTENDED to be written as documented, but is it a sin if I implement > > something else? (How would an alternate form hinder interoperability.) I looked at accepting something else when implementing EUI48 and EUI64 in named then thought about the "named accepts it so it must be right" crowd. If you want more liberal formats they need to be documented and the LCD is a MUST the rest are MAYs or SHOULDs. > > Apparently I am a little cranky today. > > ...and haven't re-read RFC 2119 in a while. There is no mention of "sin". > > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From richard.lamb@icann.org Wed Apr 17 12:22:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A391221E8047 for ; Wed, 17 Apr 2013 12:22:10 -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 k2M5xSkRnM+q for ; Wed, 17 Apr 2013 12:22:10 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4A89E21F893B for ; Wed, 17 Apr 2013 12:22:09 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 17 Apr 2013 12:22:09 -0700 From: Richard Lamb To: IETF DNSOP WG Date: Wed, 17 Apr 2013 12:22:17 -0700 Thread-Topic: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... Thread-Index: Ac46ZVEyx3p1KvSmTVafbmWdGeZBlwBOMU+Q Message-ID: <5648A8908CCB564EBF46E2BC904A75B15FF1684D02@EXVPMBX100-1.exc.icann.org> References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <20130416054223.C0E2E326C22C@drugs.dv.isc.org> In-Reply-To: <20130416054223.C0E2E326C22C@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 19:22:11 -0000 FWIW I don't see any problem with having RRtypes for MAC addresses in the D= NS. I am not an old DNS salt like many on this list, but seems there are m= any other RRtypes out there that have less interest. I see the reference t= o the IEEE "Guidelines for use of a ...EUI-48" but for the sake of equal bi= lling to this "other lookup table" it might be nice to add a reference/link= to the IEEE Registration authority for OUIs, e.g., http://standards.ieee.= org/develop/regauth/oui/public.html , in your references section. -Rick -----Original Message----- From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of M= ark Andrews Sent: Monday, April 15, 2013 10:42 PM To: Edward Lewis Cc: IETF DNSOP WG Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD spo= nsored individual sumission... In message , Edward Lewis= writes: > I have no problem with this in spirit. But I always wonder why the=20 > presentation formats, as in section 3.2 and 4.2, have MUST concerning=20 > how the record is "written." I've never considered the presentation=20 > format to be subject to a standard...I realize that's just my opinion,=20 > but the on-the-wire format is what is subject to interoperability concern= s. It's a MUST because master file format is a interchange standard. RFC 1034 The standard format of master files allows them to be exchanged between hos= ts (via FTP, mail, or some other mechanism); this facility is useful when a= n organization wants a domain, but doesn't want to support a name server. = The organization can maintain the master files locally using a text editor,= transfer them to a foreign host which runs a name server, and then arrange= with the system administrator of the name server to get the files loaded. Mark =20 > The document can have the MUSTs but I'd prefer SHOULDs. It's right=20 > that there's only one way these addresses ever get written, so the=20 > MUST seems logical, OTOH, it just seems over the top to demand it be=20 > written one way or another. I certainly understand it is INTENDED to=20 > be written as documented, but is it a sin if I implement something=20 > else? (How would an alternate form hinder interoperability.) >=20 > Apparently I am a little cranky today. >=20 > On Apr 14, 2013, at 12:08, joel jaeggli wrote: >=20 > > -------- Original Message -------- > > Subject: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored=20 > individual sumission... > > Date: Sun, 14 Apr 2013 08:55:52 -0700 > > From: joel jaeggli > > To: dnsext@ietf.org, dnsops@ietf.org > > CC: draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org > >=20 > >=20 > >=20 > > I've been asked to take this document on as AD sponsored individual=20 > > submission. > >=20 > > http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-0 > > 2 > >=20 > > If there's anyone who has strenuous objections to that, please let=20 > > me > know. > >=20 > > joel > >=20 > >=20 > >=20 > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > -=3D-=3D > - > Edward Lewis =20 > NeuStar You can leave a voice message at=20 > +1-571-434-5468 >=20 > There are no answers - just tradeoffs, decisions, and responses. >=20 >=20 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop From ek@google.com Wed Apr 17 20:31:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8F21E80FD for ; Wed, 17 Apr 2013 20:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gQq7WJVlHBp8 for ; Wed, 17 Apr 2013 20:31:32 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89521E80FB for ; Wed, 17 Apr 2013 20:31:32 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ef5so1534253obb.8 for ; Wed, 17 Apr 2013 20:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pTuNqahm/KS1A9//IYDxsl/Ef6TgUEgo70ZSktHu3cU=; b=duRPoFqKUEngRUItQzUyHrsqceFXhK7ylGs2VqTJbCm0+Pc7zlSECINwA2039PStWu 1sBjBjEKaSSkC1Iws00tO0XKC1ws8KpueGuA9b/nJK8lIEef4eIYYfCsiMTxZDIhd4lv Wmtcl62zL6cb+gsYKp/5W33dvCOU7weKYIOPbLmD6zX5QRaFMF4g+ZpRijXtgqbW9jI+ gFUnj03UwGC8vVlKv8/NcWExApEKDCGqI52rPxKCmZqIzJ9KOfFGuAzyljDOsRTRsvuj zUxXYnpUjMSACmedvClhxA8lpDc9GLvkEkKA9EzDBXOZ7w6nzJHrU5V3zijXETVqRZ+f zAZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=pTuNqahm/KS1A9//IYDxsl/Ef6TgUEgo70ZSktHu3cU=; b=Po/sUctk1Wz3Z+H6GXRCA3FsMHbYXfoxLGH6UgZnHlAgJ/w79q/FblxJufGFldJKL6 PAeC94WwsNqzctu+WY3vitQwTIZfdfcfdyG/I0+ckwDQU5PPTh3PO+/2+t+Dyxj4+dbX R0xP6iYZqyzpl3nhBImpNTrsFYanRC9YywqInHZ5EA/RpRenryvVzZVjnKLsfbtY7Qlx zN5cFF5nLz+EIi+2JzcYzWJ0xQmdsOeHc/kw/iDrykVO9qOlg2td6w6SGChFXSfsCgN4 PAVKIjviwmWobl1I+DHEteT24/V9FqUsQ/xThrO0VsJXkEx1H3d3mN1azHptB2rgKo4h 9MRw== X-Received: by 10.60.33.105 with SMTP id q9mr2541484oei.54.1366255891618; Wed, 17 Apr 2013 20:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.245.229 with HTTP; Wed, 17 Apr 2013 20:31:11 -0700 (PDT) In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B15FF1684D02@EXVPMBX100-1.exc.icann.org> References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <20130416054223.C0E2E326C22C@drugs.dv.isc.org> <5648A8908CCB564EBF46E2BC904A75B15FF1684D02@EXVPMBX100-1.exc.icann.org> From: Erik Kline Date: Thu, 18 Apr 2013 12:31:11 +0900 Message-ID: To: Richard Lamb Content-Type: multipart/alternative; boundary=089e01229c3017b22404da9a3d4e X-Gm-Message-State: ALoCoQmiWP0uhJQwhtX1OECk8y3/ay/qrqyxpTApR/h5P4Za/+puBwGXHVzuEsadrNP70JhwptoJZZNsZ+JZmIH41XNjjmlqfXB0HENPiDI6BKu5JsQZ4Kh7E5lGAeqJzl0QTFEuCCMwoMb+UBoGlCgVsYxHYl/oIHUjqOKqBt1mFgU28cIFVhApTonXqsGu6nRUT3x1UDaa Cc: IETF DNSOP WG Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 03:31:32 -0000 --089e01229c3017b22404da9a3d4e Content-Type: text/plain; charset=UTF-8 I too am not a long-standing dnsop participant, but this draft raised a question for me. Does the class have any relevance anymore, really? To be clear, I have no substantive comment on this document. But when I read "The EUI{48,64} RR is class-independent" I thought, that's a bit...weird. It seemed to me that if there were, for example, an IEEE class then this would be perfectly suitable. But I guess that the RR number-space is effectively flat? Do people even contemplate new classes anymore? Apologies for my naivete. PS: If there are clarifying statements being added it might be worth stating (the obvious) that EUI64 != Modified EUI64 as used by IPv6 SLAAC (so don't go flipping bits unnecessarily). --089e01229c3017b22404da9a3d4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I too am not a long-standing dnsop participant, but this d= raft raised a question for me. =C2=A0Does the class have any relevance anym= ore, really?

To be clear, I have no substantive comment = on this document. =C2=A0But when I read "The EUI{48,64} RR is class-in= dependent" I thought, that's a bit...weird. =C2=A0It seemed to me = that if there were, for example, an IEEE class then this would be perfectly= suitable. =C2=A0But I guess that the RR number-space is effectively flat? = =C2=A0Do people even contemplate new classes anymore?

Apologies for my naivete.

PS: If there are clarifying statements being added it might be worth stat= ing (the obvious) that EUI64 !=3D Modified EUI64 as used by IPv6 SLAAC (so = don't go flipping bits unnecessarily).
--089e01229c3017b22404da9a3d4e-- From paul@cypherpunks.ca Wed Apr 17 21:15:02 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657AA21F8960 for ; Wed, 17 Apr 2013 21:15:02 -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 HQCZU-JrDjBs for ; Wed, 17 Apr 2013 21:15:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5E18721F891D for ; Wed, 17 Apr 2013 21:14:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zrn5r1Rw6z4BL; Thu, 18 Apr 2013 00:14:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vPJIGTJEItpq; Thu, 18 Apr 2013 00:14:55 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 18 Apr 2013 00:14:55 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id D48D780DF5; Thu, 18 Apr 2013 00:14:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C807C80C15; Thu, 18 Apr 2013 00:14:55 -0400 (EDT) Date: Thu, 18 Apr 2013 00:14:55 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Erik Kline In-Reply-To: Message-ID: References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <20130416054223.C0E2E326C22C@drugs.dv.isc.org> <5648A8908CCB564EBF46E2BC904A75B15FF1684D02@EXVPMBX100-1.exc.icann.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Cc: IETF DNSOP WG , Richard Lamb Subject: Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission... X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 04:15:02 -0000 On Thu, 18 Apr 2013, Erik Kline wrote: >  But I guess that the RR number-space is effectively flat?  Do people even contemplate new classes anymore? I think most people believe new classes would lead to implementation chaos[*] Paul [*] sorry :) From jim@rfc1035.com Thu Apr 18 02:11:01 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2546121F8A48 for ; Thu, 18 Apr 2013 02:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 a66SdXz1ThO3 for ; Thu, 18 Apr 2013 02:11:00 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49021F8A3F for ; Thu, 18 Apr 2013 02:10:59 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 85B55CBC41F; Thu, 18 Apr 2013 10:10:53 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: Date: Thu, 18 Apr 2013 10:10:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <59D5C03F-904F-4414-A0C0-AF153C1DB618@rfc1035.com> References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <20130416054223.C0E2E326C22C@drugs.dv.isc.org> <5648A8908CCB564EBF46E2BC904A75B15FF1684D02@EXVPMBX100-1.exc.icann.org> To: Erik Kline X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG Subject: [DNSOP] new DNS classes for fun and profit X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 09:11:01 -0000 On 18 Apr 2013, at 04:31, Erik Kline wrote: > Do people even contemplate new classes anymore? Yes. A now dead Swiss(?) academic got paid by the ITU to promote this = idea 4-5 years ago after he presented it at WSIS and IGF. The concept = was to "increase competition" in the DNS name space. Which would have = the not entirely accidental side effect of breaking USG/ICANN hegemony = on Internet governance. His web sites and projects are no longer active, so I don't have current = URLs for his papers and slideware. google found this though: = http://www.itu.int/wsis/implementation/2009/forum/geneva/Pdfs/WSISForum09-= InfraClasses-V0%201%20(2).pdf Be sure to have lots of padding beneath your chin to soften the impact = when your jaw drops if you read this. From bortzmeyer@nic.fr Thu Apr 18 02:18:47 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEB21F88CA for ; Thu, 18 Apr 2013 02:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 hTkplqQi56Ej for ; Thu, 18 Apr 2013 02:18:46 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9436121F88BF for ; Thu, 18 Apr 2013 02:18:46 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id AB750280B0B; Thu, 18 Apr 2013 11:18:11 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id A67C4280B08; Thu, 18 Apr 2013 11:18:11 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:113]) by relay2.nic.fr (Postfix) with ESMTP id CA92EB3807F; Thu, 18 Apr 2013 11:17:18 +0200 (CEST) Date: Thu, 18 Apr 2013 11:17:18 +0200 From: Stephane Bortzmeyer To: Jim Reid Message-ID: <20130418091718.GA29436@nic.fr> References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <20130416054223.C0E2E326C22C@drugs.dv.isc.org> <5648A8908CCB564EBF46E2BC904A75B15FF1684D02@EXVPMBX100-1.exc.icann.org> <59D5C03F-904F-4414-A0C0-AF153C1DB618@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59D5C03F-904F-4414-A0C0-AF153C1DB618@rfc1035.com> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Erik Kline , IETF DNSOP WG Subject: Re: [DNSOP] new DNS classes for fun and profit X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 09:18:48 -0000 On Thu, Apr 18, 2013 at 10:10:53AM +0100, Jim Reid wrote a message of 15 lines which said: > > Do people even contemplate new classes anymore? > > Yes. A now dead Swiss(?) He was French. An analysis (in french) of his work is here: http://www.bortzmeyer.org/net4d.html From tglassey@earthlink.net Thu Apr 18 05:16:41 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2D21F8ACD for ; Thu, 18 Apr 2013 05:16:41 -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 HnWV1+UBiJIw for ; Thu, 18 Apr 2013 05:16:40 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id A23EE21F8917 for ; Thu, 18 Apr 2013 05:16:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HHL41eBFsmSdygZ7mYdbELvSdNknp6qztQylJf++OS3RvDoZyOp11fXEDQrdPKw1; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.21] (helo=[192.168.1.101]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1USnlY-0000TN-1u for dnsop@ietf.org; Thu, 18 Apr 2013 08:16:40 -0400 Message-ID: <516FE426.3010701@earthlink.net> Date: Thu, 18 Apr 2013 05:16:38 -0700 From: tsg User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsop@ietf.org References: <516AD188.1020408@bogus.com> <516AD478.8070503@bogus.com> <20130416054223.C0E2E326C22C@drugs.dv.isc.org> <5648A8908CCB564EBF46E2BC904A75B15FF1684D02@EXVPMBX100-1.exc.icann.org> <59D5C03F-904F-4414-A0C0-AF153C1DB618@rfc1035.com> In-Reply-To: <59D5C03F-904F-4414-A0C0-AF153C1DB618@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79091cae5c3f8bfeaca85eaa4c0c70b516350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.21 Subject: Re: [DNSOP] new DNS classes for fun and profit X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 12:16:41 -0000 There is no reason USE RULES on the addresses resolved cannot be published (except perhaps that certain parties in this group doesnt want that to happen for some reason). For instance - one could publish a OPT-OUT Statement for Mailing Use Rules, something that is critically needed in dealing with SPAM... That said it makes sense to extend DNS into other areas to make it less necessary at the application context to rely on its shared OS context (allows a more appliance like operation). In fact ultimately there is no reason DNS is not functionally a policy and infrastructure information lookup and publishing tool. Oh yeah - except a bunch of purists want to make sure it never evolves into something that they didnt create... This is the same crap I run into all the time with the US6370629 patent now that McNeil and I have our control back. So look - YES while this specific brief isnt maybe the best expansion - the idea has merit that there is a need for a DIGITAL CONTENT INFRASTRUCTURE LOOKUP PRACTICE for policy publication and DNS is probably the best place possible to layer that functionality INTO (not on top of). Todd On 04/18/2013 02:10 AM, Jim Reid wrote: > On 18 Apr 2013, at 04:31, Erik Kline wrote: > >> Do people even contemplate new classes anymore? > Yes. A now dead Swiss(?) academic got paid by the ITU to promote this idea 4-5 years ago after he presented it at WSIS and IGF. The concept was to "increase competition" in the DNS name space. Which would have the not entirely accidental side effect of breaking USG/ICANN hegemony on Internet governance. > > His web sites and projects are no longer active, so I don't have current URLs for his papers and slideware. google found this though: > http://www.itu.int/wsis/implementation/2009/forum/geneva/Pdfs/WSISForum09-InfraClasses-V0%201%20(2).pdf > > Be sure to have lots of padding beneath your chin to soften the impact when your jaw drops if you read this. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From ed.lewis@neustar.biz Thu Apr 18 10:27:13 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB7F21F8FD7 for ; Thu, 18 Apr 2013 10:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6RAIKDfUdsI4 for ; Thu, 18 Apr 2013 10:27:06 -0700 (PDT) Received: from smtp77.ord1c.emailsrvr.com (smtp77.ord1c.emailsrvr.com [108.166.43.77]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC421F9389 for ; Thu, 18 Apr 2013 10:27:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id ACE2F1E80B5; Thu, 18 Apr 2013 13:27:03 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 5BFB81E81AC; Thu, 18 Apr 2013 13:27:03 -0400 (EDT) From: Edward Lewis Content-Type: multipart/alternative; boundary="Apple-Mail=_075A1761-C6FA-47D0-B4A3-DCA52BCC9E44" Date: Thu, 18 Apr 2013 13:27:02 -0400 Message-Id: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> To: IETF DNSOP WG Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 17:27:22 -0000 --Apple-Mail=_075A1761-C6FA-47D0-B4A3-DCA52BCC9E44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was thinking a bit about the CDS draft, not specifically it, but the = problem it is addressing. This message was spurred by a comment that "in a key emergency where the = private key is exposed" the only way to go forward is to completely stop = DNSSEC and then do a re-start from state "0." The rationale for that = was, if I had your private key I could sign the DNSKEY set, add keys at = will and generate signatures into the future. Thus "forward security" = would always be suspect. I don't entirely agree with that. After thinking some, the reason is = that any new key in the DNS is, yes, signed by the old key, but also = relies on the presence of a "sympathenic" DS record at the parent. This = represents a "two factor" approach to authenticating the new key - = signed by the current zone administrator and also registered with the = parent through some other security barrier. For example, the new key is signed by an old key over the DNSKEY set. = And, assuming EPP, then the key has to come through the registration = system's security too. Yes, you can game either and maybe even both = injection paths, but to be effective you have to game both. Simply put, = with just basic security hygiene, it's much harder to game both than to = game either one. =46rom this, one of the important ideas is "two factor" authentication. = "Three factor" might be even more beneficial, but let's shoot for two = first. I think of the CDS proposal as having two components. One is a means to = marshall the information from child to parent. The other is the way in = which the data is transferred and handled. In concept I wholeheartedly = support the former component. It's the latter component that gives me = angina. (I.e., heart burn, but I was trying to avoid using heart twice = in the same sentence in those ways.) The marshaling is very beneficial, it's much better than the current = state of the art of cut-n-paste when the operator of the DNS is not the = editor of the registry's contents. Even if the registry wants DNSKEY = records, having an indication of the DS desire allows the registry to = get the DNSKEY unless the desire is for an un-published DNSKEY's DS = record. (Which does happen.) IMHO, I don't support adding DS records = based on DNSKEY - I say this not to mean I believe it is wrong but I say = it to mean that someone that believes this has to come up with someway = to get the un-published DNSKEY from the child to parent to accommodate = this OR declare it operationally forbidden (which is also acceptable). But when it comes to the "how" the data is transferred I have a lot of = problems. First, the draft says that the CDS has to be signed by the KSK and not a = ZSK. This is a problem to me because it's the first time an RRSIG over = data is restricted to one kind of key or another. To me that's a = precedent setter, and as such needs scrutiny. I understand that the = requirement is because the KSK manager and the ZSK manager could be = different (and are so for the root zone), but this is a change to the = protocol in a way that hasn't been explored. I think that there's = something to be learned from the two factor observation though. The most visible key management function where this plays a role is the = root. But, it doesn't play a role because the root has no parent and = thus no need to marshall the key. (In reality, the keys are marshaled = via other means, out of band and play a role in the ICANN KSK ceremonies = that happen 4 times a year.) In any other situation, the CDS ought to just be the marshaling and the = RRSIG over it just authenticating that the record got from the child to = the parent with integrity. The "out of band" environment that gets the = parent to insert the DS has got to kick in to provide the second factor. Switching to another environment, the usual case of a registrant in an = ICANN-SRM-style zone (shared registry model) using EPP and registrars, = this can play out using the following (I switch here because I believe = it is a model fot the split KSK ZSK key management system - if they = exist other than the root). The new KSK is made and a CDS set is = generated, signed, and published in the zone (omitting details on what = is in the CDS for now). The key management function then alerts the = registrar that there's a new DS needed. Today this is cut and paste and = some say that registrars want customers to log in, see ads and then make = the request. True or not, this doesn't have to change, just instead of = cut and paste, there's a notification button to click. No polling, no = looking, no pro-activeness needed by registrar. The second factor here = is logging into the registrar portal. For registries that are willing or want to poll their registrants for = CDS records, I'd caution that they might not be doing anyone a favor. = If the KSK was exposed, then a forged CDS might pass as real and the = registrant can loose control of the zone - because only one factor was = involved and the one factor was gamed. I'll end this here. I know that CDS isn't at the foremost of minds now. = There's no sense in a new draft to "compete" and we no longer have = higher bandwidth workshops to go over these ideas. So maybe this will = get some others thinking, and whether there's merit to "two factor" = approaches to key changes. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_075A1761-C6FA-47D0-B4A3-DCA52BCC9E44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I was = thinking a bit about the CDS draft, not specifically it, but the problem = it is addressing.

This message was spurred by a comment that "in = a key emergency where the private key is exposed" the only way to go = forward is to completely stop DNSSEC and then do a re-start from state = "0."  The rationale for that was, if I had your private key I could = sign the DNSKEY set, add keys at will and generate signatures into the = future.  Thus "forward security" would always be suspect.

I = don't entirely agree with that.  After thinking some, the reason is = that any new key in the DNS is, yes, signed by the old key, but also = relies on the presence of a "sympathenic" DS record at the parent. =  This represents a "two factor" approach to authenticating the new = key - signed by the current zone administrator and also registered with = the parent through some other security barrier.

For example, the = new key is signed by an old key over the DNSKEY set.  And, assuming = EPP, then the key has to come through the registration system's security = too.  Yes, you can game either and maybe even both injection paths, = but to be effective you have to game both.  Simply put, with just = basic security hygiene, it's much harder to game both than to game = either one.

=46rom this, one of the important ideas is "two = factor" authentication.  "Three factor" might be even more = beneficial, but let's shoot for two first.

I think of the CDS = proposal as having two components.  One is a means to marshall the = information from child to parent.  The other is the way in which = the data is transferred and handled.  In concept I wholeheartedly = support the former component.  It's the latter component that gives = me angina.  (I.e., heart burn, but I was trying to avoid using = heart twice in the same sentence in those ways.)

The marshaling = is very beneficial, it's much better than the current state of the art = of cut-n-paste when the operator of the DNS is not the editor of the = registry's contents.  Even if the registry wants DNSKEY records, = having an indication of the DS desire allows the registry to get the = DNSKEY unless the desire is for an un-published DNSKEY's DS record. =  (Which does happen.)  IMHO, I don't support adding DS records = based on DNSKEY - I say this not to mean I believe it is wrong but I say = it to mean that someone that believes this has to come up with someway = to get the un-published DNSKEY from the child to parent to accommodate = this OR declare it operationally forbidden (which is also = acceptable).

But when it comes to the "how" the data is = transferred I have a lot of problems.

First, the draft says that = the CDS has to be signed by the KSK and not a ZSK.  This is a = problem to me because it's the first time an RRSIG over data is = restricted to one kind of key or another.  To me that's a precedent = setter, and as such needs scrutiny.  I understand that the = requirement is because the KSK manager and the ZSK manager could be = different (and are so for the root zone), but this is a change to the = protocol in a way that hasn't been explored.  I think that there's = something to be learned from the two factor observation = though.

The most visible key management function where this plays = a role is the root.  But, it doesn't play a role because the root = has no parent and thus no need to marshall the key.  (In reality, = the keys are marshaled via other means, out of band and play a role in = the ICANN KSK ceremonies that happen 4 times a year.)

In any = other situation, the CDS ought to just be the marshaling and the RRSIG = over it just authenticating that the record got from the child to the = parent with integrity.  The "out of band" environment that gets the = parent to insert the DS has got to kick in to provide the second = factor.

Switching to another environment, the usual case of a = registrant in an ICANN-SRM-style zone (shared registry model) using EPP = and registrars, this can play out using the following (I switch here = because I believe it is a model fot the split KSK ZSK key management = system - if they exist other than the root).  The new KSK is made = and a CDS set is generated, signed, and published in the zone (omitting = details on what is in the CDS for now).  The key management = function then alerts the registrar that there's a new DS needed. =  Today this is cut and paste and some say that registrars want = customers to log in, see ads and then make the request.  True or = not, this doesn't have to change, just instead of cut and paste, there's = a notification button to click.  No polling, no looking, no = pro-activeness needed by registrar.  The second factor here is = logging into the registrar portal.

For registries that are = willing or want to poll their registrants for CDS records, I'd caution = that they might not be doing anyone a favor.  If the KSK was = exposed, then a forged CDS might pass as real and the registrant can = loose control of the zone - because only one factor was involved and the = one factor was gamed.

I'll end this here.  I know that CDS = isn't at the foremost of minds now.  There's no sense in a new = draft to "compete" and we no longer have higher bandwidth workshops to = go over these ideas.  So maybe this will get some others thinking, = and whether there's merit to "two factor" approaches to key = changes.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_075A1761-C6FA-47D0-B4A3-DCA52BCC9E44-- From wjhns1@hardakers.net Thu Apr 18 15:15:17 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C737821F9110 for ; Thu, 18 Apr 2013 15:15:17 -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 NhwT01+NJ8BA for ; Thu, 18 Apr 2013 15:15:16 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8527421F9003 for ; Thu, 18 Apr 2013 15:15:16 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:4909:acfc:1621:a4b0]) by mail.hardakers.net (Postfix) with ESMTPSA id C17BC258D3; Thu, 18 Apr 2013 15:15:14 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> Date: Thu, 18 Apr 2013 15:15:14 -0700 In-Reply-To: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> (Edward Lewis's message of "Thu, 18 Apr 2013 13:27:02 -0400") Message-ID: <0ld2tra3kd.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 22:15:17 -0000 Edward Lewis writes: [Ed's well written and long thoughts about transfer issues removed] Security vs operational practice has always been a contention. Security purists want the strictest of controls so that nothing can ever be stolen, misused, abused, modified, etc. They'd use 4-factor authentication if they could get away with it (something you have, something you know, something you are and something from another time and another galaxy that's amazingly hard to retrieve). I admit, when I lean, I lean this direction. But I've also done enough operational work in my life to know that in an ideally secure world where security is the only metric, nothing would get done. You can't leave the lead box and certainly penetrating wires wouldn't be permitted through it. But the internet itself was founded at the opposite end of the spectrum: purely concerned with operational practice. There was no need to secure IP, DNS, BGP, telnet, imap, etc. Security is often an afterthought, because the first thought is *always* "can we get it up and running quickly?". Not, "can we get it up and running quickly and securely?". Primarily because "quick security" is an oxymoron. So, as always: we're left with a need to make a balanced decision. Which is better: multi-factor authentication or real-world operational practice. Or something in between. I'll agree with you that by forcing a user over TLS to make any DS changes in the parent, you're functionally adding a second authentication form: (a really badly implemented, ad-laden, web login subject to password database theft and social engineering... but still a second authentication form). Or is it? Really it's "a different form". > If the KSK was exposed, then a forged CDS might pass as real and the > registrant can loose control of the zone - because only one factor was > involved and the one factor was gamed. If your password gets stolen, guessed, entropied away (yes, that's a verb; shut up spell checker), socialized, etc then you're just as vulnerable to a take over as if a fake CDS was inserted. It's still only "one factor", unless your registar requires two factors itself to log in (and most certainly don't). And the key/password bits needed to log in to your registrar are likely smaller than the entropy used to sign your zone. And the registrar login data is usually stored in two places: their data base and on your post-it note. Plus, as a colleague of ours frequently likes to iterate "Protecting your DNS keys with uber-security and not protecting the DNS data source itself buys you nothing -- Russ Mundy. Ish; I don't think he'd use 'uber'" If you have lost control of your zone enough that someone has inserted a CDS record, they can also insert a new KSK or ZSK to forge records with. So denying them the ability to publish a CDS record doesn't really prevent things anyway. But all of this brings me back to my starting point: security vs operation. It's not up to us to decide which zones are so critical that they should never be allowed to use CDS records because they must physical visit their registar with 5 forms of authentication (#5 being star dust from Justin Bieber's head to prove you have the right to modify JustinBieber.com). It's not up to us to deny an operator of 100k zones the ability to roll keys on a regular basis because it's easy to do and his organization has a high administrative turnover rate (Justin Bieber fan club (TM)). It's not up to us to give them absolute security or operational mandates. It's up to us to give them the tools so they can make the choices themselves for their environment. It takes the registrar and the registrant to want to publish a CDS for it to be used. Either one can decide they would prefer to use the ad-laden web page login because it's more secure or it has pretty pictures of Justin Bieber in a skin-tight racing suit. CDS is at least a decent middle ground that offers a middle point in the balance equation. It provides a decent point where security and operational practice might be at the top of the tradeoff bubble. And, that's why we have operational and security sections in RFCs in the first place: to document concerns and let the real world make their decisions based on that discussion. -- Wes Hardaker SPARTA, Inc. From jabley@hopcount.ca Thu Apr 18 17:11:19 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966DF21F912C for ; Thu, 18 Apr 2013 17:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 cj0qjCR1EOji for ; Thu, 18 Apr 2013 17:11:17 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBDD21F90EB for ; Thu, 18 Apr 2013 17:11:14 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id p13so3053697vbe.21 for ; Thu, 18 Apr 2013 17:11:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ChheW4C0Rr/K4kvdwzMz0eYFTVbtLG0wMqw2fidKAJw=; b=ibu6DTKmTnOeHey8od5j+WtQARxNJr2U+0fuV9G/ap97hVeUyvRfi7MdXgMUMqSVDj ukSQbIJ1ZCGaPD7uIz0fIok3lzcuSTSYTRlnDzbozPqGHRsBXaCsXur/H+3ShfAfSRrf 96iSbvqlm5/UJ+dXOoHSWiGKtRV+bLCmRWfOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ChheW4C0Rr/K4kvdwzMz0eYFTVbtLG0wMqw2fidKAJw=; b=c3YZZlab32GiJWCagcbYPRN8APMTAjUhS14dUQSvTDEC9B+xiY9FqbsqNdpUNXaaDZ kWuda7V4w0naB6e1EqWXF3mJK0PHumSi1PEunHMTpGRcVhVlvSRtqDuAFbbhOlM7zd8C fgIKaa20pb8CYI2aj7QTteiqSlRRYx9TL4sb/Na3WNddFqM9pS8ftiHGSo7w9loWm+RS qIHyql4K0Sbs1jMnEhNveP7TYhcaOKCDrtz4mDv+LCRzRtEhB3ubOZ9fjY8z0SogEscQ NhTI0SVHKApMapFaj5gopEDgYb6qrVX0WWryZf99sBmMnR8K68OZda5Cgn0lpLUkTuZb 94KA== X-Received: by 10.52.70.49 with SMTP id j17mr7540104vdu.67.1366330274090; Thu, 18 Apr 2013 17:11:14 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPS id oz4sm3421157veb.4.2013.04.18.17.11.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 17:11:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <0ld2tra3kd.fsf@wjh.hardakers.net> Date: Thu, 18 Apr 2013 20:11:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlxtDmcEnm5ImK/T+MaR0lRi8UGkyguXAWk9RaVh7Z1E/7dMvfXex/T50/MqEAGNcQMJ3V2 Cc: IETF DNSOP WG , Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 00:11:19 -0000 On 2013-04-18, at 18:15, Wes Hardaker wrote: > CDS is at least a decent middle ground that offers a middle point in = the > balance equation. It provides a decent point where security and > operational practice might be at the top of the tradeoff bubble. And, > that's why we have operational and security sections in RFCs in the > first place: to document concerns and let the real world make their > decisions based on that discussion. I wonder actually why we're discussing CDS at all, and are not just = sitting back and watch people deploy signed apex DS RRSets. (I = understand why we're discussing the general approach. I just don't know = why the approach is tied to a new RRType). There's no protocol meaning at present for an apex DS RRSet, which means = it ought to be harmless to add one. A parent (or the parent's agent) = could decide to act upon the presence of a signed apex DS RRSet just as = easily as it could with CDS. It might as well pick up the signed NS set = while it's there. By this thinking, a signed apex DS RRSet with the meaning discussed for = CDS could be deployed today, with no need for code point assignment. = What am I missing? Joe= From paul@redbarn.org Thu Apr 18 17:35:19 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE2021F8FB8 for ; Thu, 18 Apr 2013 17:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] 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 D7pYcdeyBx39 for ; Thu, 18 Apr 2013 17:35:03 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id C36CD21F8EAA for ; Thu, 18 Apr 2013 17:35:02 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:1951:d8ef:7d99:5709] (unknown [IPv6:2001:559:8000:cb:1951:d8ef:7d99:5709]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 6AFC3EE0B6; Fri, 19 Apr 2013 00:35:02 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <51709142.700@redbarn.org> Date: Thu, 18 Apr 2013 17:35:14 -0700 From: Paul Vixie User-Agent: Postbox 3.0.7 (Windows/20130120) MIME-Version: 1.0 To: Joe Abley References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF DNSOP WG , Edward Lewis , Wes Hardaker Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 00:35:19 -0000 Joe Abley wrote: > > There's no protocol meaning at present for an apex DS RRSet, which means it ought to be harmless to add one. A parent (or the parent's agent) could decide to act upon the presence of a signed apex DS RRSet just as easily as it could with CDS. It might as well pick up the signed NS set while it's there. because much of the dnssec infrastructure "knows" that DS is an exception to delegation, and that it's above the zone cut, there is no reliable way to query for it under the zone cut. paul From paul@nohats.ca Thu Apr 18 19:21:56 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAE621F926E for ; Thu, 18 Apr 2013 19:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 CgyC9h2boaYa for ; Thu, 18 Apr 2013 19:21:44 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id D7EA221F920B for ; Thu, 18 Apr 2013 19:21:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZsLXZ5hwBz5Jd; Thu, 18 Apr 2013 22:21:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5IquoPBjO1t7; Thu, 18 Apr 2013 22:21:33 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 18 Apr 2013 22:21:33 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E8AC180E0E; Thu, 18 Apr 2013 22:21:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DBA6080C2C; Thu, 18 Apr 2013 22:21:33 -0400 (EDT) Date: Thu, 18 Apr 2013 22:21:33 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 02:21:56 -0000 On Thu, 18 Apr 2013, Joe Abley wrote: > There's no protocol meaning at present for an apex DS RRSet, which means it ought to be harmless to add one. A parent (or the parent's agent) could decide to act upon the presence of a signed apex DS RRSet just as easily as it could with CDS. It might as well pick up the signed NS set while it's there. > > By this thinking, a signed apex DS RRSet with the meaning discussed for CDS could be deployed today, with no need for code point assignment. What am I missing? Let's not repeat root-servers.net and .net on the same nameserver leading to overly complex interpretations of old DNS clients vs new DNS clients for DS records. Or what to serve when parent and child have a different DS set on the same name server :) Paul From jabley@hopcount.ca Fri Apr 19 07:07:22 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE4021F8D2A for ; Fri, 19 Apr 2013 07:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.500, 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 55mZslndyqvn for ; Fri, 19 Apr 2013 07:07:21 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id B26DF21F8A74 for ; Fri, 19 Apr 2013 07:07:21 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id m16so3790037vca.25 for ; Fri, 19 Apr 2013 07:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=5JC4tP0ApVs+d+YWF6yrxQAl/znSMMsNoSWqQcMzIk4=; b=TR6kjYF5Zt1G7RT3lkjKKgCWMbRifCuPBzQ11f2ztXuYm7qJkeUXXg0pVweLSd/lrq F4d+kI4Pm0/9u0VVY0lQWJxbPno8CtuvxT4VwaAFfRMIkcAhIQPfV2uTzwCYPdXluPPW GnQ5RShenMeEUXvmxqcAXTSBqJ+8Rot06BG3c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=5JC4tP0ApVs+d+YWF6yrxQAl/znSMMsNoSWqQcMzIk4=; b=KZbSCuCprw2bFmPE/4z3Vj2MTNjKAe1um9asVAmcF7TTnYmsUzxenIwHugKopGOsQT T/btZ7VWTm/uALzPALands385aYSPKsFG8JX1AC6PkEd+xbsG/u77MIb/SM6WwCRCKb/ S4EDRQE2OGP74JUNRD106kfOuTLAekCPRwQ5zpyyBr4GZ5VVnhh8CNbpufeIwdTk9CHd VmiW2A0cKWnQ9nRsomiqDkee3R4aH7FNPYHSPzrpWd3EbeMqoWVv4loCOHJdULsQaHOn hdOwGSc5gO9jz33Nbsc72+wOk9mrcMO2p4lx3sYmUIjJZ8S2zVDhmkmqvjhtpRAJpRsu Jf7g== X-Received: by 10.52.72.106 with SMTP id c10mr2658550vdv.31.1366380441122; Fri, 19 Apr 2013 07:07:21 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:89d8:3212:c5b8:e25d? ([2001:4900:1042:100:89d8:3212:c5b8:e25d]) by mx.google.com with ESMTPS id xe6sm12025507vec.6.2013.04.19.07.07.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 07:07:20 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <51709142.700@redbarn.org> Date: Fri, 19 Apr 2013 10:07:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <51709142.700@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQl94WPjOXnk3ORo1wwvwU/Hv3e0HdHFsTbcYDCMqj4Y87ywQhkK6GiNl8bRdvWKYSoavy5O Cc: IETF DNSOP WG , Edward Lewis , Wes Hardaker Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:07:22 -0000 On 2013-04-18, at 20:35, Paul Vixie wrote: > Joe Abley wrote: >=20 >> There's no protocol meaning at present for an apex DS RRSet, which = means it ought to be harmless to add one. A parent (or the parent's = agent) could decide to act upon the presence of a signed apex DS RRSet = just as easily as it could with CDS. It might as well pick up the signed = NS set while it's there. >=20 > because much of the dnssec infrastructure "knows" that DS is an > exception to delegation, and that it's above the zone cut, there is no > reliable way to query for it under the zone cut. ... except that the clients that would use the apex DS RRSet are = special, in that they know precisely what servers to query. But this would not be an aid to users who would suffer troubleshooting = confusion galore, and that seems like a perfectly good reason not to do = it. Joe= From fanf2@hermes.cam.ac.uk Fri Apr 19 07:14:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A713D21F8C08 for ; Fri, 19 Apr 2013 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HxWMSqNMgRr for ; Fri, 19 Apr 2013 07:14:52 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id BA18721F8BE4 for ; Fri, 19 Apr 2013 07:14:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51102) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1UTC5Q-0006sT-6W (Exim 4.80_167-5a66dd3) (return-path ); Fri, 19 Apr 2013 15:14:48 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UTC5P-00072d-VB (Exim 4.72) (return-path ); Fri, 19 Apr 2013 15:14:47 +0100 Date: Fri, 19 Apr 2013 15:14:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Joe Abley In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <51709142.700@redbarn.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: Edward Lewis , IETF DNSOP WG , Paul Vixie , Wes Hardaker Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:14:53 -0000 Joe Abley wrote: > > ... except that the clients that would use the apex DS RRSet are > special, in that they know precisely what servers to query. That isn't enough to disambiguate which DS is being asked for if child and parent zones share a server. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jabley@hopcount.ca Fri Apr 19 07:16:02 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6321F8E51 for ; Fri, 19 Apr 2013 07:16:02 -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 K5xqNWvjWqBt for ; Fri, 19 Apr 2013 07:16:01 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E221F8E04 for ; Fri, 19 Apr 2013 07:16:01 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id ia10so3799665vcb.26 for ; Fri, 19 Apr 2013 07:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=e5p1Pl266A2pg62pbP45x/jiqFzCy+/Pq+aQKx2llpM=; b=iVZI/3tVbR1OcNQBf8T0zZ/8O6D8pHcbbFhC+luEDvJxx6qmfYSBroLLmF08slypMi cmFMMwH6BIPvU1elJERPDjtFM9mUEAe/HNqodR2iVn03ScRJcAYoQb/o4LPBOHIda2kJ OCpVpvvdbVNXQ/eXOj8S4KpQ+c+bxfNOvAAuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=e5p1Pl266A2pg62pbP45x/jiqFzCy+/Pq+aQKx2llpM=; b=bG4ck5zvHVfuxnks5SwZv+Wulzyt12w8v5Yq+cWF8yrFqa7DlFirkRajsX39ZVOXub QMLK+feD3moSZrubJ9exkVm8CdSNUSvqKUWTnlHkpiXDdkwsfueLMXR5WA+2D6Elv9j8 7GBMogQ77RbotoOemIao0pwLJvNUjMd1zCljeWLwdgAsgUMDH6HE7Agu+sVs3ZkHd1ue 4IRkGKBmgBzzt7Br2Vul26OhSryoMHD7f1EGV7aiX0C1/lSKN8LAGOnXUqiMrNOft6qT X/QfQAgs928zbek6tzX6pKD0J0izS5v/e6EgbDs9CIJbDhc63pUa4IPj/vDkRd1YWqY4 bVpA== X-Received: by 10.52.233.225 with SMTP id tz1mr10210847vdc.54.1366380960744; Fri, 19 Apr 2013 07:16:00 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPS id 6sm13866790vei.0.2013.04.19.07.15.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 07:16:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Fri, 19 Apr 2013 10:15:56 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <51709142.700@redbarn.org> To: Tony Finch X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlt6kxlWbVzOk+JWoEWV+9OaJRDxhP4fUSV0SITCDZa7QgqajQfk02k2IlANQtCXrnWencF Cc: Edward Lewis , IETF DNSOP WG , Paul Vixie , Wes Hardaker Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:16:02 -0000 On 2013-04-19, at 10:14, Tony Finch wrote: > Joe Abley wrote: > >> ... except that the clients that would use the apex DS RRSet are >> special, in that they know precisely what servers to query. > > That isn't enough to disambiguate which DS is being asked for if child and > parent zones share a server. Ah yes, also that. OK, I've thrown it in the bad idea bucket. :-) Joe From ed.lewis@neustar.biz Fri Apr 19 07:23:29 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A204821F90AC for ; Fri, 19 Apr 2013 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 Gg3IH2zDA7Uq for ; Fri, 19 Apr 2013 07:23:29 -0700 (PDT) Received: from smtp149.ord.emailsrvr.com (smtp149.ord.emailsrvr.com [173.203.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8435F21F919D for ; Fri, 19 Apr 2013 07:23:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp23.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 0244A1C8145; Fri, 19 Apr 2013 10:23:26 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp23.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id C5AFB1C8099; Fri, 19 Apr 2013 10:23:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_164A917E-4711-454C-881F-51FF6B04B736" From: Edward Lewis In-Reply-To: Date: Fri, 19 Apr 2013 10:23:29 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <51709142.700@redbarn.org> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:23:29 -0000 --Apple-Mail=_164A917E-4711-454C-881F-51FF6B04B736 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2013, at 10:15, Joe Abley wrote: > Ah yes, also that. OK, I've thrown it in the bad idea bucket. :-) One of the regrets about DNS design is that we used NS above and below = the zone cut. That complicated DNSSEC. We resisted the temptation to have KEY (later called DNSKEY) at both = parent and child because of the issues. NSEC, yes, sigh, it was a = headache but we scaled that mountain. So, "in the big book of boo-boos" (to quote Doc McStuffins), we should = avoid having the same type appear above and below a cut. It pays to = have a separate name - even if that alone is the difference (in the = presentation format ;)). = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_164A917E-4711-454C-881F-51FF6B04B736 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Ah yes, also that. OK, = I've thrown it in the bad idea bucket. = :-)

One of the regrets about = DNS design is that we used NS above and below the zone cut.  That = complicated DNSSEC.

We resisted the temptation to = have KEY (later called DNSKEY) at both parent and child because of the = issues.  NSEC, yes, sigh, it was a headache but we scaled that = mountain.

So, "in the big book of boo-boos" (to = quote Doc McStuffins), we should avoid having the same type appear above = and below a cut.  It pays to have a separate name - even if that = alone is the difference (in the presentation format = ;)).

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_164A917E-4711-454C-881F-51FF6B04B736-- From paul@redbarn.org Fri Apr 19 07:55:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196B21F8FED for ; Fri, 19 Apr 2013 07:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.265 X-Spam-Level: X-Spam-Status: No, score=-1.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, 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 2tnoZfcTCGti for ; Fri, 19 Apr 2013 07:55:34 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35F7F21F9289 for ; Fri, 19 Apr 2013 07:55:33 -0700 (PDT) Received: from [IPV6:2001:559:8000:c9:e189:dfe:54e9:c7b0] (unknown [IPv6:2001:559:8000:c9:e189:dfe:54e9:c7b0]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 4CB6DEDAE5; Fri, 19 Apr 2013 14:55:24 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <51709142.700@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----21MRZXKI6R6KAA70TMFKR3D74UROK5" From: P Vixie Date: Fri, 19 Apr 2013 07:55:23 -0700 To: Edward Lewis ,IETF DNSOP WG Message-ID: Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:55:35 -0000 ------21MRZXKI6R6KAA70TMFKR3D74UROK5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ns, above and below, was easy to handle even in dnssec, since it was always part of the delegation and was only signed in the child. Making any other rrtype above and below would be much harder since it would not automatically be exposed on every referral. The boo boo was putting ds at the delegation point. Had we put it at _ds._dnssec.$delegationpoint then it would have an unambiguous location in the parent and could be queried via non dnssec aware middle boxes. Which would make stub validation a lot more practical. Oh well. Paul Edward Lewis wrote: > >On Apr 19, 2013, at 10:15, Joe Abley wrote: > >> Ah yes, also that. OK, I've thrown it in the bad idea bucket. :-) > > >One of the regrets about DNS design is that we used NS above and below >the zone cut. That complicated DNSSEC. > >We resisted the temptation to have KEY (later called DNSKEY) at both >parent and child because of the issues. NSEC, yes, sigh, it was a >headache but we scaled that mountain. > >So, "in the big book of boo-boos" (to quote Doc McStuffins), we should >avoid having the same type appear above and below a cut. It pays to >have a separate name - even if that alone is the difference (in the >presentation format ;)). > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis >NeuStar You can leave a voice message at >+1-571-434-5468 > >There are no answers - just tradeoffs, decisions, and responses. > > > >------------------------------------------------------------------------ > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------21MRZXKI6R6KAA70TMFKR3D74UROK5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ns, above and below, was easy to handle even in dnssec, since it was always part of the delegation and was only signed in the child. Making any other rrtype above and below would be much harder since it would not automatically be exposed on every referral.

The boo boo was putting ds at the delegation point. Had we put it at _ds._dnssec.$delegationpoint then it would have an unambiguous location in the parent and could be queried via non dnssec aware middle boxes. Which would make stub validation a lot more practical. Oh well.

Paul

Edward Lewis <ed.lewis@neustar.biz> wrote:

On Apr 19, 2013, at 10:15, Joe Abley wrote:

Ah yes, also that. OK, I've thrown it in the bad idea bucket. :-)

One of the regrets about DNS design is that we used NS above and below the zone cut.  That complicated DNSSEC.

We resisted the temptation to have KEY (later called DNSKEY) at both parent and child because of the issues.  NSEC, yes, sigh, it was a headache but we scaled that mountain.

So, "in the big book of boo-boos" (to quote Doc McStuffins), we should avoid having the same type appear above and below a cut.  It pays to have a separate name - even if that alone is the difference (in the presentation format ;)).

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

There are no answers - just tradeoffs, decisions, and responses.
 


DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------21MRZXKI6R6KAA70TMFKR3D74UROK5-- From paul@redbarn.org Fri Apr 19 07:57:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C6421F944A for ; Fri, 19 Apr 2013 07:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.632 X-Spam-Level: X-Spam-Status: No, score=-8.632 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, RCVD_IN_DNSWL_HI=-8] 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 wxQgvYGekARj for ; Fri, 19 Apr 2013 07:57:31 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id DD09421F8FAC for ; Fri, 19 Apr 2013 07:57:30 -0700 (PDT) Received: from [IPV6:2001:559:8000:c9:e189:dfe:54e9:c7b0] (unknown [IPv6:2001:559:8000:c9:e189:dfe:54e9:c7b0]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 645E1EBCE9; Fri, 19 Apr 2013 14:57:30 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <51709142.700@redbarn.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F00GAY78NISBNJ53JWQC0A3MA19JR0" From: P Vixie Date: Fri, 19 Apr 2013 07:57:29 -0700 To: Joe Abley Message-ID: Cc: IETF DNSOP WG , Edward Lewis , Wes Hardaker Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 14:57:32 -0000 ------F00GAY78NISBNJ53JWQC0A3MA19JR0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Joe the special clients still have to forward through middle boxes sometimes. This special rule won't be known there. Paul Joe Abley wrote: > >On 2013-04-18, at 20:35, Paul Vixie wrote: > >> Joe Abley wrote: >> >>> There's no protocol meaning at present for an apex DS RRSet, which >means it ought to be harmless to add one. A parent (or the parent's >agent) could decide to act upon the presence of a signed apex DS RRSet >just as easily as it could with CDS. It might as well pick up the >signed NS set while it's there. >> >> because much of the dnssec infrastructure "knows" that DS is an >> exception to delegation, and that it's above the zone cut, there is >no >> reliable way to query for it under the zone cut. > >... except that the clients that would use the apex DS RRSet are >special, in that they know precisely what servers to query. > >But this would not be an aid to users who would suffer troubleshooting >confusion galore, and that seems like a perfectly good reason not to do >it. > > >Joe -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------F00GAY78NISBNJ53JWQC0A3MA19JR0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Joe the special clients still have to forward through middle boxes sometimes. This special rule won't be known there.

Paul

Joe Abley <jabley@hopcount.ca> wrote:

On 2013-04-18, at 20:35, Paul Vixie <paul@redbarn.org> wrote:

Joe Abley wrote:

There's no protocol meaning at present for an apex DS RRSet, which means it ought to be harmless to add one. A parent (or the parent's agent) could decide to act upon the presence of a signed apex DS RRSet just as easily as it could with CDS. It might as well pick up the signed NS set while it's there.

because much of the dnssec infrastructure "knows" that DS is an
exception to delegation, and that it's above the zone cut, there is no
reliable way to query for it under the zone cut.

... excep
 t that
the clients that would use the apex DS RRSet are special, in that they know precisely what servers to query.

But this would not be an aid to users who would suffer troubleshooting confusion galore, and that seems like a perfectly good reason not to do it.


Joe

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------F00GAY78NISBNJ53JWQC0A3MA19JR0-- From wjhns1@hardakers.net Fri Apr 19 08:21:30 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8421F941F for ; Fri, 19 Apr 2013 08:21:30 -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 ChmKzDpjK34Y for ; Fri, 19 Apr 2013 08:21:30 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A1C21F93F8 for ; Fri, 19 Apr 2013 08:21:30 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:b50c:b806:9ef4:a339]) by mail.hardakers.net (Postfix) with ESMTPSA id 906CB256D2; Fri, 19 Apr 2013 08:21:29 -0700 (PDT) From: Wes Hardaker To: Joe Abley References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> Date: Fri, 19 Apr 2013 08:21:29 -0700 In-Reply-To: (Joe Abley's message of "Thu, 18 Apr 2013 20:11:10 -0400") Message-ID: <0lip3i1r7q.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG , Edward Lewis , Wes Hardaker Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:21:31 -0000 Joe Abley writes: > By this thinking, a signed apex DS RRSet with the meaning discussed > for CDS could be deployed today, with no need for code point > assignment. What am I missing? Besides the other two comments: DS records are signed with the ZSK, and the CDS document explains why it needs to be signed with the KSK instead (also). -- Wes Hardaker SPARTA, Inc. From jabley@hopcount.ca Fri Apr 19 08:28:27 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECED21F9602 for ; Fri, 19 Apr 2013 08:28:27 -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 pKyb7fBbFLFA for ; Fri, 19 Apr 2013 08:28:27 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id DED9221F95FF for ; Fri, 19 Apr 2013 08:28:26 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lf11so1771773vcb.20 for ; Fri, 19 Apr 2013 08:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=obtK9aoi3FnOzl3V4jjLCVxUMxWUkEnHRHigZB2y+M8=; b=EUZYlNOgqMZ5tvYdL33+Amdq92np/h+AvflaZ74uhn+94B21HDlh2/5vKl4F86Oygl IAb6G0en1A7s1iol6SdBns8WYGkXwq/3FgRSGHQgKU+ifMFeM4TXDbq8JzBVnIuFNEfU sY+4ArAPZKqruAG0jyK6tWN7TKXecF2HH/UfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=obtK9aoi3FnOzl3V4jjLCVxUMxWUkEnHRHigZB2y+M8=; b=PQbtsAwLF9xUb2o3Wyua32wNZrwOAfTft4WE1ysF0vz3fHJ6LLduPUTI2DN7iYuklI qxguCYmb7h5iFarI7FbncR8prusmIY8Tq7XpDxg879Ti/Qwx+sY+NS4zmCQVOPTP1gNr 9OeZ3vu4++FGa7PWe5wj9L5PTN+dol524lfmVB8aJIy7b7f/AGX/Z1Ht+E9aK3zsLKzv GbRnUmjoeuRiI1+/ywz/2lG8EjEplqI8kWRpX0JW/79WvLtLOJf4w93btOfIWmv1JXS2 yZ2Dh4LHQsjg1i03vtbokna8NYGhFidTxFP5I+SVzS81ih6QfcRgyhxptSNS7r4r58cT B3Nw== X-Received: by 10.220.57.197 with SMTP id d5mr11809138vch.47.1366385306111; Fri, 19 Apr 2013 08:28:26 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPS id qq6sm14111075vec.2.2013.04.19.08.28.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 08:28:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <0lip3i1r7q.fsf@wjh.hardakers.net> Date: Fri, 19 Apr 2013 11:28:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQk9w4jv4uMATHsvlG+CdXYqxITZgKdfhhQ2jVoH/cM4NtCeiOtGFNmvh44A7KEWir4KA3mU Cc: IETF DNSOP WG , Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:28:27 -0000 On 2013-04-19, at 11:21, Wes Hardaker wrote: > Joe Abley writes: >=20 >> By this thinking, a signed apex DS RRSet with the meaning discussed >> for CDS could be deployed today, with no need for code point >> assignment. What am I missing? >=20 > Besides the other two comments: DS records are signed with the ZSK, = and > the CDS document explains why it needs to be signed with the KSK = instead > (also). I'm not sure I fully understand the logic of that, actually. Surely the important thing is that the apex CDS RRSet in the child zone = can be verified to be authentic. Whether that means that CDS has an = RRSIG created by a KSK or a ZSK should make no difference, so long as = the chain of trust from the parent zone is intact. Why is it not sufficient to specify that the authenticity of the CDS = RRSet in the child zone should be able to be verified using DNSSEC, or = else that the CDS RRSet should be ignored? Joe= From ed.lewis@neustar.biz Fri Apr 19 08:29:23 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132B421F86E8 for ; Fri, 19 Apr 2013 08:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.868 X-Spam-Level: X-Spam-Status: No, score=-101.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 JkBFFWtlv2U5 for ; Fri, 19 Apr 2013 08:29:22 -0700 (PDT) Received: from smtp205.dfw.emailsrvr.com (smtp205.dfw.emailsrvr.com [67.192.241.205]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2521F867B for ; Fri, 19 Apr 2013 08:29:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id CEF891B8225; Fri, 19 Apr 2013 11:29:21 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp10.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 874721B8178; Fri, 19 Apr 2013 11:29:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_648BBC70-7350-4C1C-8411-E6619B178BF9" From: Edward Lewis In-Reply-To: <0lip3i1r7q.fsf@wjh.hardakers.net> Date: Fri, 19 Apr 2013 11:29:20 -0400 Message-Id: <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:29:23 -0000 --Apple-Mail=_648BBC70-7350-4C1C-8411-E6619B178BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2013, at 11:21, Wes Hardaker wrote: > Besides the other two comments: DS records are signed with the ZSK, = and > the CDS document explains why it needs to be signed with the KSK = instead > (also). That is one of the things I don't like about the CDS semantics. I don't = want special signing rules and would hope that using a "second factor" = would suffice. When it comes to the root zone, the example given to me as the = justification for this, CDS wouldn't apply and if it did, there's the = second factor being the transport of the keys via the KSR and specific = steps in the KSK ceremony script. (For some reason, when I try to write = this, I lose the terminology I want to use.) I am unconvinced that the special signing rules mentioned in the draft = are warranted and is one of the main reasons I am not a supporter of the = draft. I have a fundamental objection to that specific provision. Yes, = even understanding the rationale for it, I don't buy the reason. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_648BBC70-7350-4C1C-8411-E6619B178BF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Besides= the other two comments: DS records are signed with the ZSK, and
the = CDS document explains why it needs to be signed with the KSK = instead
(also).

That is one of = the things I don't like about the CDS semantics.  I don't want = special signing rules and would hope that using a "second factor" would = suffice.

When it comes to the root zone, the = example given to me as the justification for this, CDS wouldn't apply = and if it did, there's the second factor being the transport of the keys = via the KSR and specific steps in the KSK ceremony script.  (For = some reason, when I try to write this, I lose the terminology I want to = use.)

I am unconvinced that the special signing = rules mentioned in the draft are warranted and is one of the main = reasons I am not a supporter of the draft.  I have a fundamental = objection to that specific provision.  Yes, even understanding the = rationale for it, I don't buy the reason.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_648BBC70-7350-4C1C-8411-E6619B178BF9-- From paul@nohats.ca Fri Apr 19 08:33:59 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622E121F88FB for ; Fri, 19 Apr 2013 08:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 BFWOfLESCF8x for ; Fri, 19 Apr 2013 08:33:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 94EA921F859C for ; Fri, 19 Apr 2013 08:33:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zsh6p3Dkpz7DL; Fri, 19 Apr 2013 11:33:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id UuDvSpD-s1DW; Fri, 19 Apr 2013 11:33:53 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 19 Apr 2013 11:33:53 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id C196280E0F; Fri, 19 Apr 2013 11:33:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B6B7E80C2C; Fri, 19 Apr 2013 11:33:53 -0400 (EDT) Date: Fri, 19 Apr 2013 11:33:53 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:33:59 -0000 On Fri, 19 Apr 2013, Joe Abley wrote: >> Besides the other two comments: DS records are signed with the ZSK, and >> the CDS document explains why it needs to be signed with the KSK instead >> (also). > > I'm not sure I fully understand the logic of that, actually. > > Surely the important thing is that the apex CDS RRSet in the child zone can be verified to be authentic. and that it is signed by the KSK holder - not the ZSK holder. If the parent would update its DS based on the child's ZSK's signature, then the ZSK is used as KSK and the ZSK holder can bypass the KSK, and thus seperation of duties and/or different HSM/storage/security is bypassed. Paul From ogud@ogud.com Fri Apr 19 08:37:12 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEA921F9621 for ; Fri, 19 Apr 2013 08:37:12 -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 k3XVnn+FG44d for ; Fri, 19 Apr 2013 08:37:11 -0700 (PDT) Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) by ietfa.amsl.com (Postfix) with ESMTP id AB01521F8266 for ; Fri, 19 Apr 2013 08:37:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5444F1B00E6; Fri, 19 Apr 2013 11:37:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id EE18F1B00DC; Fri, 19 Apr 2013 11:37:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olafur Gudmundsson In-Reply-To: Date: Fri, 19 Apr 2013 11:37:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> To: Joe Abley X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG , Edward Lewis , Wes Hardaker Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:37:12 -0000 On Apr 19, 2013, at 11:28 AM, Joe Abley wrote: >=20 > On 2013-04-19, at 11:21, Wes Hardaker wrote: >=20 >> Joe Abley writes: >>=20 >>> By this thinking, a signed apex DS RRSet with the meaning discussed >>> for CDS could be deployed today, with no need for code point >>> assignment. What am I missing? >>=20 >> Besides the other two comments: DS records are signed with the ZSK, = and >> the CDS document explains why it needs to be signed with the KSK = instead >> (also). >=20 > I'm not sure I fully understand the logic of that, actually. >=20 > Surely the important thing is that the apex CDS RRSet in the child = zone can be verified to be authentic. Whether that means that CDS has an = RRSIG created by a KSK or a ZSK should make no difference, so long as = the chain of trust from the parent zone is intact. >=20 > Why is it not sufficient to specify that the authenticity of the CDS = RRSet in the child zone should be able to be verified using DNSSEC, or = else that the CDS RRSet should be ignored? Flippant answer: in the case where same entity operates both KSK and ZSK = keys, just use singe key in both roles.=20 Serious answer: CDS becomes part of the Trust Anchor authentication = chain, in RFC5011 Trust Anchor Maintainers only accept new trust anchors = that are signed by the old Trust Anchor, and CDS copied that requirement.=20 Olafur From ed.lewis@neustar.biz Fri Apr 19 08:58:22 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A268A21F93F0 for ; Fri, 19 Apr 2013 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 sV0-I81M-HBb for ; Fri, 19 Apr 2013 08:58:21 -0700 (PDT) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id BC39721F8FA5 for ; Fri, 19 Apr 2013 08:58:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6B6E23C04DB; Fri, 19 Apr 2013 11:58:21 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp9.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 05BFC3C049D; Fri, 19 Apr 2013 11:58:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_66DFBEA0-4522-4F75-B98F-EE75E5C0752B" From: Edward Lewis In-Reply-To: <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> Date: Fri, 19 Apr 2013 11:58:19 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:58:22 -0000 --Apple-Mail=_66DFBEA0-4522-4F75-B98F-EE75E5C0752B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2013, at 11:37, Olafur Gudmundsson wrote: >=20 > Serious answer: CDS becomes part of the Trust Anchor authentication = chain, in RFC5011 Trust Anchor Maintainers only accept new trust anchors = that > are signed by the old Trust Anchor, and CDS copied that requirement.=20= I don't buy into that. That 5011 depends on "X" (which is fine) does = not imply to me that the CDS has to also have that requirement. Once 5011 believes the new trust anchor is earnest, why does this need = to be further checked? And, in the case of a compromise of a key's secrecy, which I see as a = problem for 5011, is the situation any better if the CDS is signed by a = KSK? The point I am coming back to is that if a ZSK is exposed, false RRSIGs = will validate until the ZSK disappears from the DNSKEY set (in caches). = The zone administrator can roll out of the compromised ZSK to eventually = end the abuse - but in the interim the false ZSK can be used to extend = signatures over the DNSKEY for a very long time. Only when the DS set = (which is beyond the ZSK's reach) eliminates a chain through the ZSK can = the abuse end. Question: If you get a DNSKEY set that has these records: $TTL=3D1 week ZSK - compromised KSK - "safe" RRSIG by KSK good from now until May 1, 2013 RRSIG by ZSK good from now until December 31, 2038 would you validate this on April 30, 2013 and hold it for a week? = Assuming that there's still a DS record that "works?" (Would this = extend the damage?) I.e., sometimes rolling out the ZSK isn't enough, the KSK/DS has to go = too. It seems to me that no matter what key is compromised, KSK or ZSK - or = even a CSK - the DS has to be changed. The DS is a "second factor" here = because it would take a different key compromise to game that (assuming = cross-organizational delegations). Sorry folks, this discussion is probably a bit much in email, but it's = the only venue we have. I appreciate the reluctance to have long, = boring yes/no debates, but I think there's some fundamental issues to = hammer out first. When I say I'm unconvinced, I don't mean the = requirement is wrong, I mean that I don't see a clear reason for what I = think is potentially just an invitation for yet another corner case. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_66DFBEA0-4522-4F75-B98F-EE75E5C0752B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Serious = answer: CDS becomes part of the Trust Anchor authentication chain, in = RFC5011 Trust Anchor Maintainers only accept new trust anchors = that
are signed by the old Trust Anchor, and CDS copied that = requirement.

I don't = buy into that.  That 5011 depends on "X" (which is fine) does not = imply to me that the CDS has to also have that = requirement.

Once 5011 believes the new trust = anchor is earnest, why does this need to be further = checked?

And, in the case of a compromise of a = key's secrecy, which I see as a problem for 5011, is the situation any = better if the CDS is signed by a KSK?

The point = I am coming back to is that if a ZSK is exposed, false RRSIGs will = validate until the ZSK disappears from the DNSKEY set (in caches). =  The zone administrator can roll out of the compromised ZSK to = eventually end the abuse - but in the interim the false ZSK can be used = to extend signatures over the DNSKEY for a very long time.  Only = when the DS set (which is beyond the ZSK's reach) eliminates a chain = through the ZSK can the abuse end.

Question: If = you get a DNSKEY set that has these = records:

$TTL=3D1 week
ZSK - = compromised
KSK - "safe"
RRSIG by KSK good from now = until May 1, 2013
RRSIG by ZSK good from now until December = 31, 2038

would you validate this on April 30, = 2013 and hold it for a week?  Assuming that there's still a DS = record that "works?"  (Would this extend the = damage?)

I.e., sometimes rolling out the ZSK = isn't enough, the KSK/DS has to go too.

It = seems to me that no matter what key is compromised, KSK or ZSK - or even = a CSK - the DS has to be changed.  The DS is a "second factor" here = because it would take a different key compromise to game that (assuming = cross-organizational delegations).

Sorry folks, = this discussion is probably a bit much in email, but it's the only venue = we have.  I appreciate the reluctance to have long, boring yes/no = debates, but I think there's some fundamental issues to hammer out = first.  When I say I'm unconvinced, I don't mean the requirement is = wrong, I mean that I don't see a clear reason for what I think is = potentially just an invitation for yet another corner = case.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_66DFBEA0-4522-4F75-B98F-EE75E5C0752B-- From fanf2@hermes.cam.ac.uk Fri Apr 19 09:33:14 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6D921F8F5D for ; Fri, 19 Apr 2013 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7XoV9z05Aew for ; Fri, 19 Apr 2013 09:33:13 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 6594621F8F05 for ; Fri, 19 Apr 2013 09:33:13 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:50709) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1UTEFM-0002OL-8S (Exim 4.80_167-5a66dd3) (return-path ); Fri, 19 Apr 2013 17:33:12 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UTEFM-00073q-IU (Exim 4.72) (return-path ); Fri, 19 Apr 2013 17:33:12 +0100 Date: Fri, 19 Apr 2013 17:33:12 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Edward Lewis In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> 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: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 16:33:14 -0000 Edward Lewis wrote: > > The point I am coming back to is that if a ZSK is exposed, false RRSIGs > will validate until the ZSK disappears from the DNSKEY set (in caches). > The zone administrator can roll out of the compromised ZSK to eventually > end the abuse - but in the interim the false ZSK can be used to extend > signatures over the DNSKEY for a very long time. Only when the DS set > (which is beyond the ZSK's reach) eliminates a chain through the ZSK can > the abuse end. The lifetime of this kind of compromise is limited by the expiry time of the KSK's RRSIG over the DNSKEY RRset. The attacker with the compromised ZSK can't extend this since they can't re-sign the DNSKEYs in a way that will be authenticated by the DS. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From paul@nohats.ca Fri Apr 19 09:41:13 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B219921F8FAC for ; Fri, 19 Apr 2013 09:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 mLy89AKtfB7d for ; Fri, 19 Apr 2013 09:41:13 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2792721F8F4F for ; Fri, 19 Apr 2013 09:41:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZsjcP3sJgz9Yt; Fri, 19 Apr 2013 12:41:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wg3IKaSQX8GS; Fri, 19 Apr 2013 12:41:09 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 19 Apr 2013 12:41:08 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 5C87280E0F; Fri, 19 Apr 2013 12:41:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 42B7380C2C; Fri, 19 Apr 2013 12:41:08 -0400 (EDT) Date: Fri, 19 Apr 2013 12:41:08 -0400 (EDT) From: Paul Wouters To: Tony Finch In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 16:41:13 -0000 On Fri, 19 Apr 2013, Tony Finch wrote: > The lifetime of this kind of compromise is limited by the expiry time of > the KSK's RRSIG over the DNSKEY RRset. The attacker with the compromised > ZSK can't extend this since they can't re-sign the DNSKEYs in a way that > will be authenticated by the DS. Which is why the ZSK should never be trusted for a RRSIG over CDS to update the DS recors, because then it could cycle the existing KSK out of the DNSKEY RRset. Paul From jabley@hopcount.ca Fri Apr 19 10:07:31 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1DA21F95E9 for ; Fri, 19 Apr 2013 10:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFTmKm531h8m for ; Fri, 19 Apr 2013 10:07:30 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4BA21F95DB for ; Fri, 19 Apr 2013 10:07:30 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x13so3849559vbb.20 for ; Fri, 19 Apr 2013 10:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=8GZEVNCoDMp0C3BWCFrm8zz81bOdEjUnetfwkWBT1eA=; b=S9VWWRH+doeFSsGmf3Z5FGC8ZBKKlTrB+egjl7pPD+T7qiga0UhNJCkvTqXtcYVuzC KXxho3vkPKxEdZELKMujk2tCaeiHi7H32VQAMbLDlkGGRPy/AVuVV7HMNQ7KkcEbrtrm V2Sr5sRWFnp9V2mrrnebBaIZuC0IVQiultnX8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8GZEVNCoDMp0C3BWCFrm8zz81bOdEjUnetfwkWBT1eA=; b=byiIPkrYxxD3nyt9UOnP0haBC3ChlrUI9oGW2RnJGmSsqV7IFKJHPJ0FSGjEjt2eIA 2N4P4gyncxMQE1+GZrwO2FBym0Og4rHYFXhwVKbBahJC+9cmO038m21a6ln1/eNgdD8K uOB71Ij83+BRmz7OBCQwFpDfv3pO5yM6RKqmrzeSQP42zNhYJKfdaIplFoA2Vw9cYhkt B8og7yk4nXuOSrAK+QVh02irCf2CddGvdxPEFklUnGJMvxJYGfhtuTCD54gyxOO4+IcU 1qLBEI8NutwchNquX3AMHd005bHwr8gtmAF5Q2dvxHwRkRdubsbQlbtrGuJxq8JPuQQN OjpQ== X-Received: by 10.52.176.65 with SMTP id cg1mr10439836vdc.1.1366391249698; Fri, 19 Apr 2013 10:07:29 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:856a:2ca:9612:62de? ([2001:4900:1042:100:856a:2ca:9612:62de]) by mx.google.com with ESMTPS id d16sm14575521vdh.11.2013.04.19.10.07.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 10:07:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Fri, 19 Apr 2013 13:07:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <13F3C1ED-9469-450D-8C99-010CA3FC704A@hopcount.ca> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> To: Paul Wouters X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnpbYyhiUMRRRLvzOSoL+oDT5D1KuZkjIdmaAcQGrJtdK4SelDVso2jOHqpNloRN2uFZpxG Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:07:31 -0000 On 2013-04-19, at 11:33, Paul Wouters wrote: > On Fri, 19 Apr 2013, Joe Abley wrote: >=20 >>> Besides the other two comments: DS records are signed with the ZSK, = and >>> the CDS document explains why it needs to be signed with the KSK = instead >>> (also). >>=20 >> I'm not sure I fully understand the logic of that, actually. >>=20 >> Surely the important thing is that the apex CDS RRSet in the child = zone can be verified to be authentic. >=20 > and that it is signed by the KSK holder - not the ZSK holder. If the > parent would update its DS based on the child's ZSK's signature, then > the ZSK is used as KSK and the ZSK holder can bypass the KSK, and thus > seperation of duties and/or different HSM/storage/security is = bypassed. I understand that concern, but I think we need to be pragmatic and avoid = being overly prescriptive. If an individual zone maintainer's processes impose a separation of = duties between KSK management and ZSK management, then they should make = decisions that they are comfortable with. The decisions as to how any = CDS RRSet should be signed are in the right place, and I don't think = it's sensible to require that the parent make assumptions about what is = good or bad practice at the child. I think that documenting these concerns (to encourage people to think = about them) is sensible. I don't think it's sensible to make assumptions and prohibit behaviour = that in many cases might be perfectly sensible. Joe= From ed.lewis@neustar.biz Fri Apr 19 10:15:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01D021F9423 for ; Fri, 19 Apr 2013 10:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 W4UjgcqTmADK for ; Fri, 19 Apr 2013 10:15:11 -0700 (PDT) Received: from smtp133.ord.emailsrvr.com (smtp133.ord.emailsrvr.com [173.203.6.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5493421F8F05 for ; Fri, 19 Apr 2013 10:15:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id C6FC23F00B7; Fri, 19 Apr 2013 13:15:07 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 959CF3F0103; Fri, 19 Apr 2013 13:15:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8AAE38B9-1CC9-4CE1-8090-F586D0B4B9DB" From: Edward Lewis In-Reply-To: Date: Fri, 19 Apr 2013 13:15:07 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:15:12 -0000 --Apple-Mail=_8AAE38B9-1CC9-4CE1-8090-F586D0B4B9DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2013, at 12:33, Tony Finch wrote: >=20 > The lifetime of this kind of compromise is limited by the expiry time = of > the KSK's RRSIG over the DNSKEY RRset. The attacker with the = compromised > ZSK can't extend this since they can't re-sign the DNSKEYs in a way = that > will be authenticated by the DS. The question is whether the expiry of the KSK matters more than the = expiry of the ZSK. The case we are talking about here is the ZSK being compromised. What I = was also thinking about is a compromise of the KSK. Or more accurately, = compromise of the SEP. I'm trying to work out whether it's sufficient to just roll out of the = ZSK to end the suffering of a compromise (realizing that there's the = signature effectivity and ttls to expire) or if you'd have to roll the = KSK too - assuming a ZSK (non-SEP) compromise. It's clear that if the = SEP is compromised, I have to clear it out of the DS set. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_8AAE38B9-1CC9-4CE1-8090-F586D0B4B9DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The lifetime = of this kind of compromise is limited by the expiry time of
the KSK's = RRSIG over the DNSKEY RRset. The attacker with the compromised
ZSK = can't extend this since they can't re-sign the DNSKEYs in a way = that
will be authenticated by the = DS.

The question is = whether the expiry of the KSK matters more than the expiry of the = ZSK.

The case we are talking about here is the = ZSK being compromised.  What I was also thinking about is a = compromise of the KSK.  Or more accurately, compromise of the = SEP.

I'm trying to work out whether it's = sufficient to just roll out of the ZSK to end the suffering of a = compromise (realizing that there's the signature effectivity and ttls to = expire) or if you'd have to roll the KSK too - assuming a ZSK (non-SEP) = compromise.  It's clear that if the SEP is compromised, I have to = clear it out of the DS set.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_8AAE38B9-1CC9-4CE1-8090-F586D0B4B9DB-- From ed.lewis@neustar.biz Fri Apr 19 10:22:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87AD21F9608 for ; Fri, 19 Apr 2013 10:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 waF7H08RZoSB for ; Fri, 19 Apr 2013 10:22:47 -0700 (PDT) Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) by ietfa.amsl.com (Postfix) with ESMTP id 223B721F9601 for ; Fri, 19 Apr 2013 10:22:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 96AB41B8095; Fri, 19 Apr 2013 13:22:46 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id F2A9F1B8085; Fri, 19 Apr 2013 13:22:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_F675D63E-F616-4A63-AE14-CF717D1B31A8" From: Edward Lewis In-Reply-To: Date: Fri, 19 Apr 2013 13:22:43 -0400 Message-Id: <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:22:48 -0000 --Apple-Mail=_F675D63E-F616-4A63-AE14-CF717D1B31A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2013, at 12:41, Paul Wouters wrote: > Which is why the ZSK should never be trusted for a RRSIG over CDS to > update the DS recors, because then it could cycle the existing KSK out > of the DNSKEY RRset. My response is that the CDS should not automatically cause a change to = the DS, just marshall the data. I am pushing to rely on a second factor (the security over the c&c = channel to the parent) to verify the request. I'm not comfortable with in-band scraping. PS - What if the KSK/SEP is compromised? Then the attacker can roll the = legitimate KSK out and replace it with their own (assuming that they = could do it as described). = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_F675D63E-F616-4A63-AE14-CF717D1B31A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Which is why the ZSK = should never be trusted for a RRSIG over CDS to
update the DS recors, = because then it could cycle the existing KSK out
of the DNSKEY = RRset.

My response is that = the CDS should not automatically cause a change to the DS, just marshall = the data.

I am pushing to rely on a second factor = (the security over the c&c channel to the parent) to verify the = request.

I'm not comfortable with in-band = scraping.

PS - What if the KSK/SEP is = compromised?  Then the attacker can roll the legitimate KSK out and = replace it with their own (assuming that they could do it as = described).

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_F675D63E-F616-4A63-AE14-CF717D1B31A8-- From paul.hoffman@vpnc.org Fri Apr 19 10:36:26 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48A21F85A2 for ; Fri, 19 Apr 2013 10:36:26 -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 EUIGRivCzCN7 for ; Fri, 19 Apr 2013 10:36:25 -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 A022E21F859B for ; Fri, 19 Apr 2013 10:36:25 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3JHaN6f030004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Apr 2013 10:36:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> Date: Fri, 19 Apr 2013 10:36:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C7884AF-8EF1-4883-B2CF-7A602D385D86@vpnc.org> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> To: Edward Lewis X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:36:26 -0000 On Apr 19, 2013, at 10:22 AM, Edward Lewis wrote: > I am pushing to rely on a second factor (the security over the c&c = channel to the parent) to verify the request. But what if that second factor is compromised?!?! :-) As Wes pointed out, the choice is adding in more things that an attacker = must surmount versus making the normal thing happen easily. In every system that requires authentication for an action to happen, = there will be chances of compromise of the authentication mechanism. = Operators get to decide how much they care about that. --Paul Hoffman= From ed.lewis@neustar.biz Fri Apr 19 11:45:03 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3521F9075 for ; Fri, 19 Apr 2013 11:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 ylJmRyebouJ1 for ; Fri, 19 Apr 2013 11:45:03 -0700 (PDT) Received: from smtp175.dfw.emailsrvr.com (smtp175.dfw.emailsrvr.com [67.192.241.175]) by ietfa.amsl.com (Postfix) with ESMTP id 219C921F8EFE for ; Fri, 19 Apr 2013 11:45:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id AE83F258424; Fri, 19 Apr 2013 14:45:02 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 6262B25840E; Fri, 19 Apr 2013 14:45:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9CC21BE4-6EDF-4614-AD60-BF8AA1389CCC" From: Edward Lewis In-Reply-To: <3C7884AF-8EF1-4883-B2CF-7A602D385D86@vpnc.org> Date: Fri, 19 Apr 2013 14:45:00 -0400 Message-Id: <394375C9-FB08-427C-9DD4-91ED15B2F36C@neustar.biz> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <3C7884AF-8EF1-4883-B2CF-7A602D385D86@vpnc.org> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:45:04 -0000 --Apple-Mail=_9CC21BE4-6EDF-4614-AD60-BF8AA1389CCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2013, at 13:36, Paul Hoffman wrote: > But what if that second factor is compromised?!?! :-) I'm going out on a limb but I believe compromising two things is harder = than compromising just one. Perhaps "harder or just as hard as" but not = "is easier". At some point, the question is - what if the earth blows up? Seriously...so what I'm trying to do is make sure operators have the = chance to do things right. If the IETF comes up with a process that has = a single point of security engineering failure, it's a single point of = failure in operations. If there are two or more factors, it is possible for me to split the = roles around my organization. I might not, but I have the ability to do = so. I work in a fairly large organization. If you look at just one line or = business we have a separation between those that push the DS record = around and those that have access to the key management machinery. In = another area, some of the bits of this are embedded (or will be) in a = completely separate location (architecturally) from the other half. = (I'm not diving into that detail.) We didn't try to make "it" two factor, but that's the way it has = naturally fallen out. And it turns out to be a good thing. It's harder = to corrupt the practice. Again, that wasn't the goal, but in thinking = over CDS and our position - and see a nice alignment. I'm not saying it's always this way. For smaller operations these = functions might reside in one place, one person. And if we were forced = to use a one-factor way, we'd work it but the result would be less than = optimal. What I'm hammering is - give me, the operator, the ability to do my job = right. I'm a bit frustrated when I'm handed technology that assumes = I'll make the wrong choices and tries to shoe horn my operations into = the one true way. That stifles innovation. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_9CC21BE4-6EDF-4614-AD60-BF8AA1389CCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
But = what if that second factor is compromised?!?! = :-)

I'm going out on a limb = but I believe compromising two things is harder than compromising just = one.  Perhaps "harder or just as hard as" but not "is = easier".

At some point, the question is - what if the = earth blows up?

Seriously...so what I'm trying = to do is make sure operators have the chance to do things right. =  If the IETF comes up with a process that has a single point of = security engineering failure, it's a single point of failure in = operations.

If there are two or more factors, = it is possible for me to split the roles around my organization.  I = might not, but I have the ability to do so.

I = work in a fairly large organization.  If you look at just one line = or business we have a separation between those that push the DS record = around and those that have access to the key management machinery. =  In another area, some of the bits of this are embedded (or will = be) in a completely separate location (architecturally) from the other = half.  (I'm not diving into that = detail.)

We didn't try to make "it" two factor, = but that's the way it has naturally fallen out.  And it turns out = to be a good thing.  It's harder to corrupt the practice. =  Again, that wasn't the goal, but in thinking over CDS and our = position - and see a nice alignment.

I'm not = saying it's always this way.  For smaller operations these = functions might reside in one place, one person.  And if we were = forced to use a one-factor way, we'd work it but the result would be = less than optimal.

What I'm hammering is - give = me, the operator, the ability to do my job right.  I'm a bit = frustrated when I'm handed technology that assumes I'll make the wrong = choices and tries to shoe horn my operations into the one true way. =  That stifles innovation.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_9CC21BE4-6EDF-4614-AD60-BF8AA1389CCC-- From paul@nohats.ca Fri Apr 19 12:02:33 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F4621F9427 for ; Fri, 19 Apr 2013 12:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 yo5xEZazRKzJ for ; Fri, 19 Apr 2013 12:02:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1521F95E1 for ; Fri, 19 Apr 2013 12:02:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZsmlT1zNnz9by; Fri, 19 Apr 2013 15:02:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DyKeMZyEtdWU; Fri, 19 Apr 2013 15:02:28 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 19 Apr 2013 15:02:28 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id BFD5D80E0F; Fri, 19 Apr 2013 15:02:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B466C805CC; Fri, 19 Apr 2013 15:02:27 -0400 (EDT) Date: Fri, 19 Apr 2013 15:02:27 -0400 (EDT) From: Paul Wouters To: Edward Lewis In-Reply-To: <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:02:33 -0000 On Fri, 19 Apr 2013, Edward Lewis wrote: > My response is that the CDS should not automatically cause a change to the DS, just marshall the data. > I am pushing to rely on a second factor (the security over the c&c channel to the parent) to verify the request. We don't need the CDS to do that. We already have EPP for that. We _are_ trying to automate this. That's the whole point of CDS. > I'm not comfortable with in-band scraping. That's fine. Don't publish CDS as a child, or ignore CDS as a parent. > PS - What if the KSK/SEP is compromised?  Then the attacker can roll the legitimate KSK out and replace it with > their own (assuming that they could do it as described). If the KSK is compromised, they likely can redirect email too, so making a registry password reset is not that far off either. Paul From ed.lewis@neustar.biz Fri Apr 19 12:26:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD4A21F90AC for ; Fri, 19 Apr 2013 12:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 xPK6RxpvkP0D for ; Fri, 19 Apr 2013 12:26:45 -0700 (PDT) Received: from smtp115.dfw.emailsrvr.com (smtp115.dfw.emailsrvr.com [67.192.241.115]) by ietfa.amsl.com (Postfix) with ESMTP id 9C71121F902D for ; Fri, 19 Apr 2013 12:26:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp11.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 3328CD0623; Fri, 19 Apr 2013 15:26:45 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp11.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 6C5C1D0629; Fri, 19 Apr 2013 15:26:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BF030F97-C41C-4C14-B7BC-40C38F936074" From: Edward Lewis In-Reply-To: Date: Fri, 19 Apr 2013 15:26:43 -0400 Message-Id: <9B0D2E87-5D93-43C0-9EE5-7B38E43920F3@neustar.biz> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:26:46 -0000 --Apple-Mail=_BF030F97-C41C-4C14-B7BC-40C38F936074 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 19, 2013, at 15:02, Paul Wouters wrote: >=20 > We don't need the CDS to do that. We already have EPP for that. We = _are_ > trying to automate this. That's the whole point of CDS. No, "we" don't. "I'm" a DNS service operator. "I'm" not a registrar. = There is no EPP server that will accept a connection from us (if we had = an EPP client.) Please remember that the entire world is not subject to ICANN = requirements nor follows it's advice. (This is not a slam on ICANN, = their heart is in the right place. But they are not a monopoly.) It's = not "our" choice anyway. Imagine that I am serving a customer base that = collectively has 10 delegations in each and every TLD out there. And = some customers are just subdomains of an enterprise DNS set up. Think = about that end of the connection. In as much as a the Internet is not the Web...for DNS operators, CDS = could fill a gap that is not currently addressed. > That's fine. Don't publish CDS as a child, or ignore CDS as a parent. How do my customers then get the DS from our servers to their = registration systems (registrars with EPP or not)? The state of the art = is cut and paste for most. Without a standard here, we are stuck with a = lowest common denominator situation. > If the KSK is compromised, they likely can redirect email too, so = making > a registry password reset is not that far off either. This expression is an example of what I'm trying to fight. The IETF = should not assume anything about how operators work. Seriously. I have to sound insulting, but does the IETF really think operators are = idiots? This is why I'm so frustrated. We protect our businesses. For = the most part, "things work." =46rom what I see on these lists I'd = think that all that operators ever do is fraught with peril and nothing = is progressing. I.e., don't assume that email is the only way we = communicate. Don't assume registry passwords are protected one way or = another... Sorry - it's Friday. It's been a long week. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_BF030F97-C41C-4C14-B7BC-40C38F936074 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

We don't need = the CDS to do that. We already have EPP for that. We _are_
trying to = automate this. That's the whole point of = CDS.

No, "we" don't.  "I'm" a = DNS service operator.  "I'm" not a registrar.  There is no EPP = server that will accept a connection from us (if we had an EPP = client.)

Please remember that the entire world = is not subject to ICANN requirements nor follows it's advice. =  (This is not a slam on ICANN, their heart is in the right place. =  But they are not a monopoly.)  It's not "our" choice anyway. =  Imagine that I am serving a customer base that collectively has 10 = delegations in each and every TLD out there.  And some customers = are just subdomains of an enterprise DNS set up.  Think about that = end of the connection.

In as much as a the = Internet is not the Web...for DNS operators, CDS could fill a gap that = is not currently addressed.

That's = fine. Don't publish CDS as a child, or ignore CDS as a = parent.

How do my customers then = get the DS from our servers to their registration systems (registrars = with EPP or not)?  The state of the art is cut and paste for most. =  Without a standard here, we are stuck with a lowest common = denominator situation.

If the KSK = is compromised, they likely can redirect email too, so making
a = registry password reset is not that far off = either.

This expression = is an example of what I'm trying to fight.  The IETF should not = assume anything about how operators work. =  Seriously.

I have to sound insulting, but = does the IETF really think operators are idiots?  This is why I'm = so frustrated.  We protect our businesses.  For the most part, = "things work."  =46rom what I see on these lists I'd think that all = that operators ever do is fraught with peril and nothing is progressing. =  I.e., don't assume that email is the only way we communicate. =  Don't assume registry passwords are protected one way or = another...

Sorry - it's Friday.  It's been = a long week.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_BF030F97-C41C-4C14-B7BC-40C38F936074-- From fanf2@hermes.cam.ac.uk Fri Apr 19 13:41:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EA421F8F06 for ; Fri, 19 Apr 2013 13:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 666q+v0KJY8B for ; Fri, 19 Apr 2013 13:41:31 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id 7C28821F8F00 for ; Fri, 19 Apr 2013 13:41:31 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53694) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1UTI7W-0005yN-1w (Exim 4.80_167-5a66dd3) (return-path ); Fri, 19 Apr 2013 21:41:22 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UTI7W-0005CS-HN (Exim 4.72) (return-path ); Fri, 19 Apr 2013 21:41:22 +0100 Date: Fri, 19 Apr 2013 21:41:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: joe.abley@icann.org, jakob@kirei.se, gubailey@microsoft.com, dnssec-deployment@dnssec-deployment.org, dnsop@ietf.org Message-ID: 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: dot@dotat.at Subject: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:41:32 -0000 This is a followup to my comments on ICANN's root zone KSK rollover consultation. In the last section, responding to question 7 about "other considerations", I made a number of suggestions for improvements to the trust anchor publication mechanism. http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/msg00013.html The most important is the last paragraph: : I understand that ICANN would like to include third party signatures on : the root trust anchor publication web site. This would be a very good : thing, since it would allow out-of-band update software to require a : quorum of valid signatures instead of just one. This improves : security, since compromise of a single key does not compromise the : whole process. It improves robustness, since signing keys will be able : to change without breaking existing software that uses those keys for : validation, so long as a quorum of old-enough keys remain in use. Basically I want a machine-verifiable version of this: http://dns.icann.org/ksk/ds19036/ The risk is that the key used to sign the KSK, and the CA used to authenticate the key, are both single points of failure. There is no single point of failure in the quorum-of-witnesses scheme. The keys can all be simply self-signed since individual keys are only slightly trusted; the trust comes from agreement between several independent signatures. Here are some more suggestions. Related to the previous risk, there are some operational and organizational single points of failure in the publication web site - for instance it is vulnerable to DNS and BGP screwups. This can be mitigated using a system of mirror sites. A more serious risk: the current publication scheme is vulnerable to replay attacks. If the KSK is compromised, an attacker might be able to force a victim to download and trust an old version of the trust anchor publication document. To mitigate this the trust anchor document (or its signatures) should have an explicit lifetime. Validators should refresh their copy of the trust anchor document before it expires. They should remember the most recent version they have seen and refuse to downgrade to an old version. They should probably also keep track of which DNSKEYs have been retired and refuse to trust them forever more. There is perhaps an opportunity to improve on RFC 5011, in particular to reduce the time to recover from a compromised KSK without pre-publishing standby keys. If a validator sees a change in the set of KSKs, it fetches and verifies the trust anchor document in order to authenticate the change. This can lead to the validator immediately trusting the new KSK and distrusting the old one. A rollover should take effect globally in roughly the TTL of the DNSKEY RRset - two days for the root at the moment. The old KSK has to remain actively used for signing the DNSKEY RRset during the rollover for a couple of reasons: first, you seriously do not want an attacker to be able to use a bogus DNSKEY RRset to force a validator to attempt a trust anchor update; second, it's desirable to let the validator continue using its existing trust anchor during the update process since that will be relatively slow. I think it makes sense to distinguish between a trust anchor refresh / update, which occurs during continuous operation of the validator, and which is only triggered by the age of the trust anchor document or by a validated change in the DNSKEY KSKs; and trust anchor bootstrap, which occurs when the validator has been offline long enough that its existing trust anchors do not work. In normal operation, failure to validate the root should be treated as an attack or a severely broken local network, and the right reaction is not to attempt an update. Bootstrapping is relatively risky and should only occur when the system is started or wakes up after a long sleep. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From steve@shinkuro.com Fri Apr 19 13:54:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0625221F8E66 for ; Fri, 19 Apr 2013 13:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[AWL=1.905, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=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 DEK9YlyvBxa5 for ; Fri, 19 Apr 2013 13:54:38 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2502721F8E51 for ; Fri, 19 Apr 2013 13:54:37 -0700 (PDT) Received: from dummy.name; Fri, 19 Apr 2013 20:54:37 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steve Crocker In-Reply-To: Date: Fri, 19 Apr 2013 16:54:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Finch X-Mailer: Apple Mail (2.1499) Cc: joe.abley@icann.org, gubailey@microsoft.com, dnsop@ietf.org, jakob@kirei.se, dnssec-deployment@dnssec-deployment.org, Steve Crocker Subject: Re: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:54:39 -0000 Tony, Nice post. This reminds me of some thinking along these lines I did = several years ago, which was based on the analogy of how stock market = prices are published. (Things have shifted quite a bit with the = availability of real-time feeds on the Internet, so give me some = latitude here.) In the "old days" most people would get closing stock market prices from = their newspaper. Newspapers were not primary authorities, of course, = but they were trusted publishers. Each person could choose which paper = to read, and if a particular paper were to screw up the publication of = the stock market page, readers would have quickly switched to another = publisher. The application of that scheme to the present issue is to allow multiple = "publishers" sign and promulgate the root key. For automated operation = it's best if they all use the same publication format. Each user could = then choose any of the available publishers. If a publisher were to = publish the wrong information, it be evident very quickly and the = consequences would be relatively painful. If someone is paranoid about the possibility of being spoofed, he can = compare the results from multiple publishers and/or rotate among the = many publishers. But there's no need for the publishers to coordinate = among themselves, except for the standard format, and there's no need = for a formal quorum of witnesses. (I guess if someone wanted to = advocate a best practice of using a quorum of witnesses, that's ok with = me, but I view that as an added layer, not necessarily required.) Steve On Apr 19, 2013, at 4:41 PM, Tony Finch wrote: > This is a followup to my comments on ICANN's root zone KSK rollover > consultation. In the last section, responding to question 7 about = "other > considerations", I made a number of suggestions for improvements to = the > trust anchor publication mechanism. > = http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/msg00= 013.html >=20 > The most important is the last paragraph: >=20 > : I understand that ICANN would like to include third party signatures = on > : the root trust anchor publication web site. This would be a very = good > : thing, since it would allow out-of-band update software to require a > : quorum of valid signatures instead of just one. This improves > : security, since compromise of a single key does not compromise the > : whole process. It improves robustness, since signing keys will be = able > : to change without breaking existing software that uses those keys = for > : validation, so long as a quorum of old-enough keys remain in use. >=20 > Basically I want a machine-verifiable version of this: > http://dns.icann.org/ksk/ds19036/ >=20 > The risk is that the key used to sign the KSK, and the CA used to > authenticate the key, are both single points of failure. There is no > single point of failure in the quorum-of-witnesses scheme. The keys = can > all be simply self-signed since individual keys are only slightly = trusted; > the trust comes from agreement between several independent signatures. >=20 > Here are some more suggestions. >=20 > Related to the previous risk, there are some operational and > organizational single points of failure in the publication web site - = for > instance it is vulnerable to DNS and BGP screwups. This can be = mitigated > using a system of mirror sites. >=20 > A more serious risk: the current publication scheme is vulnerable to > replay attacks. If the KSK is compromised, an attacker might be able = to > force a victim to download and trust an old version of the trust = anchor > publication document. To mitigate this the trust anchor document (or = its > signatures) should have an explicit lifetime. Validators should = refresh > their copy of the trust anchor document before it expires. They should > remember the most recent version they have seen and refuse to = downgrade to > an old version. They should probably also keep track of which DNSKEYs = have > been retired and refuse to trust them forever more. >=20 > There is perhaps an opportunity to improve on RFC 5011, in particular = to > reduce the time to recover from a compromised KSK without = pre-publishing > standby keys. If a validator sees a change in the set of KSKs, it = fetches > and verifies the trust anchor document in order to authenticate the > change. This can lead to the validator immediately trusting the new = KSK > and distrusting the old one. A rollover should take effect globally in > roughly the TTL of the DNSKEY RRset - two days for the root at the = moment. >=20 > The old KSK has to remain actively used for signing the DNSKEY RRset > during the rollover for a couple of reasons: first, you seriously do = not > want an attacker to be able to use a bogus DNSKEY RRset to force a > validator to attempt a trust anchor update; second, it's desirable to = let > the validator continue using its existing trust anchor during the = update > process since that will be relatively slow. >=20 > I think it makes sense to distinguish between a trust anchor refresh / > update, which occurs during continuous operation of the validator, and > which is only triggered by the age of the trust anchor document or by = a > validated change in the DNSKEY KSKs; and trust anchor bootstrap, which > occurs when the validator has been offline long enough that its = existing > trust anchors do not work. In normal operation, failure to validate = the > root should be treated as an attack or a severely broken local = network, > and the right reaction is not to attempt an update. Bootstrapping is > relatively risky and should only occur when the system is started or = wakes > up after a long sleep. >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at = first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate = or good, > occasionally poor at first. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From fanf2@hermes.cam.ac.uk Fri Apr 19 14:18:12 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682D021F92EC for ; Fri, 19 Apr 2013 14:18:12 -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 fwBjm7u31eI6 for ; Fri, 19 Apr 2013 14:18:11 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 545BB21F92CF for ; Fri, 19 Apr 2013 14:18:11 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53033) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1UTIgt-0002oi-hs (Exim 4.80_167-5a66dd3) (return-path ); Fri, 19 Apr 2013 22:17:55 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UTIgt-0008Sb-HY (Exim 4.72) (return-path ); Fri, 19 Apr 2013 22:17:55 +0100 Date: Fri, 19 Apr 2013 22:17:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Steve Crocker In-Reply-To: Message-ID: References: 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: joe.abley@icann.org, Tony Finch , gubailey@microsoft.com, dnsop@ietf.org, jakob@kirei.se, dnssec-deployment@dnssec-deployment.org Subject: Re: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 21:18:12 -0000 Steve Crocker wrote: > > Nice post. Thanks! > If someone is paranoid about the possibility of being spoofed, he can > compare the results from multiple publishers and/or rotate among the > many publishers. But there's no need for the publishers to coordinate > among themselves, except for the standard format, and there's no need > for a formal quorum of witnesses. (I guess if someone wanted to > advocate a best practice of using a quorum of witnesses, that's ok with > me, but I view that as an added layer, not necessarily required.) I think robustness is at least as important as paranoia. I have in mind something like DNS root server operations. It's fine if D-root renumbers, because a resolver still has 12 other servers it can use to bootstrap. Similarly, a validator should have several witness keys it can use to bootstrap, so that it still works after keys are retired. If you know multiple witness keys then it becomes fairly easy to require a quorum rather than trust just one of them. The advantage is that you don't have to make an active choice about who to trust or who not to trust, which is an enormous usability bonus for mass-market validation. I'm unsure about the logistics. There are lots of plausible options. How does each witness decide they are signing the right thing? It would be nice (efficient) if a client could download a bundle of signatures from any mirror site, but does that introduce too much coupling? Maybe the witnesses could cross-mirror each other. But I though mirror sites might be provided by big CDN services, and witnesses might be interested parties such as registries, registrars, DNS software vendors, etc. usw. Your newspaper analogy is another useful model to consider. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From anne-marie.eklund-lowinder@iis.se Fri Apr 19 22:40:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41921F8E46 for ; Fri, 19 Apr 2013 22:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.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 5VK6Ff6AxNQb for ; Fri, 19 Apr 2013 22:40:09 -0700 (PDT) Received: from relay2.iis.se (relay2.iis.se [IPv6:2a00:801:f0:211::147]) by ietfa.amsl.com (Postfix) with ESMTP id BD15A21F8E36 for ; Fri, 19 Apr 2013 22:40:04 -0700 (PDT) Received: from EXCH2K7HUB-BRG.office.nic.se (unknown [212.247.3.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay2.iis.se (Postfix) with ESMTPS id DA3A14001E3; Sat, 20 Apr 2013 05:40:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=iis.se; s=r2iis; t=1366436402; bh=y9YQLIfQFuRTJShlC4fohbjmBkREK5rb39U+v6N0sUU=; h=From:To:CC:Date:Subject:Message-ID:Content-Type:MIME-Version; b=f2NiXQ3Z1//mH9UQ4GvHyU0oADjdZZ30Jrb26sIA7Ybt20wKJnlnq2j+CIFJrH7x8 /mpiJ+xZ0FbPl42i/NK2xwXa3z/stTR8a93c+gAXa4g6LKXfLtnmvLLPC9TFPo9cDA 8A8B8q1c8CzpU61OKLHEFlFMLM2tPFEItre8cqaA= Received: from Exchange2k7.office.nic.se ([fe80::306a:1c24:db16:43cb]) by EXCH2K7HUB-BRG.office.nic.se ([fe80::5cfa:6854:d17d:fe06%10]) with mapi; Sat, 20 Apr 2013 07:40:01 +0200 From: =?iso-8859-1?Q?Anne-Marie_Eklund-L=F6winder?= To: Steve Crocker , Tony Finch Date: Sat, 20 Apr 2013 07:40:00 +0200 Thread-Topic: Ang.: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor Thread-Index: AQHOPYmA/csXdBCEoEeYy4h4QGjCZA== Message-ID: Accept-Language: sv-SE Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE Content-Type: multipart/alternative; boundary="_000_A45EDA9B668744B394AB32CC561DD26Diisse_" MIME-Version: 1.0 Cc: "joe.abley@icann.org" , "gubailey@microsoft.com" , "dnsop@ietf.org" , Jakob Schlyter , "dnssec-deployment@dnssec-deployment.org" , Steve Crocker Subject: [DNSOP] Ang.: RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 05:40:11 -0000 --_000_A45EDA9B668744B394AB32CC561DD26Diisse_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As you may read from our comments, we used to publish our key in a wide spr= ead computer magazine. To get it machine readable, maybe we finally will ge= t use of the qr code that everyone hates so much! /Anne-Marie Skickat fr=E5n min HTC ----- Reply message ----- Fr=E5n: "Steve Crocker" Till: "Tony Finch" Kopia: "joe.abley@icann.org" , "gubailey@microsoft.com= " , "dnsop@ietf.org" , "Jakob Schly= ter" , "dnssec-deployment@dnssec-deployment.org" , "Steve Crocker" Rubrik: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor Datum: fre, apr 19, 2013 23:54 Tony, Nice post. This reminds me of some thinking along these lines I did severa= l years ago, which was based on the analogy of how stock market prices are = published. (Things have shifted quite a bit with the availability of real-= time feeds on the Internet, so give me some latitude here.) In the "old days" most people would get closing stock market prices from th= eir newspaper. Newspapers were not primary authorities, of course, but the= y were trusted publishers. Each person could choose which paper to read, a= nd if a particular paper were to screw up the publication of the stock mark= et page, readers would have quickly switched to another publisher. The application of that scheme to the present issue is to allow multiple "p= ublishers" sign and promulgate the root key. For automated operation it's = best if they all use the same publication format. Each user could then cho= ose any of the available publishers. If a publisher were to publish the wr= ong information, it be evident very quickly and the consequences would be r= elatively painful. If someone is paranoid about the possibility of being spoofed, he can compa= re the results from multiple publishers and/or rotate among the many publis= hers. But there's no need for the publishers to coordinate among themselve= s, except for the standard format, and there's no need for a formal quorum = of witnesses. (I guess if someone wanted to advocate a best practice of us= ing a quorum of witnesses, that's ok with me, but I view that as an added l= ayer, not necessarily required.) Steve On Apr 19, 2013, at 4:41 PM, Tony Finch wrote: > This is a followup to my comments on ICANN's root zone KSK rollover > consultation. In the last section, responding to question 7 about "other > considerations", I made a number of suggestions for improvements to the > trust anchor publication mechanism. > http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/msg0= 0013.html > > The most important is the last paragraph: > > : I understand that ICANN would like to include third party signatures on > : the root trust anchor publication web site. This would be a very good > : thing, since it would allow out-of-band update software to require a > : quorum of valid signatures instead of just one. This improves > : security, since compromise of a single key does not compromise the > : whole process. It improves robustness, since signing keys will be able > : to change without breaking existing software that uses those keys for > : validation, so long as a quorum of old-enough keys remain in use. > > Basically I want a machine-verifiable version of this: > http://dns.icann.org/ksk/ds19036/ > > The risk is that the key used to sign the KSK, and the CA used to > authenticate the key, are both single points of failure. There is no > single point of failure in the quorum-of-witnesses scheme. The keys can > all be simply self-signed since individual keys are only slightly trusted= ; > the trust comes from agreement between several independent signatures. > > Here are some more suggestions. > > Related to the previous risk, there are some operational and > organizational single points of failure in the publication web site - for > instance it is vulnerable to DNS and BGP screwups. This can be mitigated > using a system of mirror sites. > > A more serious risk: the current publication scheme is vulnerable to > replay attacks. If the KSK is compromised, an attacker might be able to > force a victim to download and trust an old version of the trust anchor > publication document. To mitigate this the trust anchor document (or its > signatures) should have an explicit lifetime. Validators should refresh > their copy of the trust anchor document before it expires. They should > remember the most recent version they have seen and refuse to downgrade t= o > an old version. They should probably also keep track of which DNSKEYs hav= e > been retired and refuse to trust them forever more. > > There is perhaps an opportunity to improve on RFC 5011, in particular to > reduce the time to recover from a compromised KSK without pre-publishing > standby keys. If a validator sees a change in the set of KSKs, it fetches > and verifies the trust anchor document in order to authenticate the > change. This can lead to the validator immediately trusting the new KSK > and distrusting the old one. A rollover should take effect globally in > roughly the TTL of the DNSKEY RRset - two days for the root at the moment= . > > The old KSK has to remain actively used for signing the DNSKEY RRset > during the rollover for a couple of reasons: first, you seriously do not > want an attacker to be able to use a bogus DNSKEY RRset to force a > validator to attempt a trust anchor update; second, it's desirable to let > the validator continue using its existing trust anchor during the update > process since that will be relatively slow. > > I think it makes sense to distinguish between a trust anchor refresh / > update, which occurs during continuous operation of the validator, and > which is only triggered by the age of the trust anchor document or by a > validated change in the DNSKEY KSKs; and trust anchor bootstrap, which > occurs when the validator has been offline long enough that its existing > trust anchors do not work. In normal operation, failure to validate the > root should be treated as an attack or a severely broken local network, > and the right reaction is not to attempt an update. Bootstrapping is > relatively risky and should only occur when the system is started or wake= s > up after a long sleep. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at fir= st. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or g= ood, > occasionally poor at first. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --_000_A45EDA9B668744B394AB32CC561DD26Diisse_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As you may read from our co= mments, we used to publish our key in a wide spread computer magazine. To g= et it machine readable, maybe we finally will get use of the qr code that e= veryone hates so much! /Anne-Marie

Skickat fr=E5n min HTC

----- Reply message -----
Fr=E5n: &qu= ot;Steve Crocker" <steve@shinkuro.com>
Till: "Tony Finch= " <dot@dotat.at>
Kopia: "joe.abley@icann.org" <j= oe.abley@icann.org>, "gubailey@microsoft.com" <gubailey@mic= rosoft.com>, "dnsop@ietf.org" <dnsop@ietf.org>, "Ja= kob Schlyter" <jakob@kirei.se>, "dnssec-deployment@dnssec-d= eployment.org" <dnssec-deployment@dnssec-deployment.org>, "= Steve Crocker" <steve@shinkuro.com>
Rubrik: [DNSOP] RISKS and= mitigations for draft-jabley-dnssec-trust-anchor
Datum: fre, apr 19, 20= 13 23:54



Tony,

Nice post.  This reminds me of some thinking along these lines I did s= everal years ago, which was based on the analogy of how stock market prices= are published.  (Things have shifted quite a bit with the availabilit= y of real-time feeds on the Internet, so give me some latitude here.)

In the "old days" most people would get closing stock market pric= es from their newspaper.  Newspapers were not primary authorities, of = course, but they were trusted publishers.  Each person could choose wh= ich paper to read, and if a particular paper were to screw up the publicati= on of the stock market page, readers would have quickly switched to another= publisher.

The application of that scheme to the present issue is to allow multiple &q= uot;publishers" sign and promulgate the root key.  For automated = operation it's best if they all use the same publication format.  Each= user could then choose any of the available publishers.  If a publish= er were to publish the wrong information, it be evident very quickly and th= e consequences would be relatively painful.

If someone is paranoid about the possibility of being spoofed, he can compa= re the results from multiple publishers and/or rotate among the many publis= hers.  But there's no need for the publishers to coordinate among them= selves, except for the standard format, and there's no need for a formal qu= orum of witnesses.  (I guess if someone wanted to advocate a best prac= tice of using a quorum of witnesses, that's ok with me, but I view that as = an added layer, not necessarily required.)

Steve



On Apr 19, 2013, at 4:41 PM, Tony Finch <dot@dotat.at> wrote:

> This is a followup to my comments on ICANN's root zone KSK rollover > consultation. In the last section, responding to question 7 about &quo= t;other
> considerations", I made a number of suggestions for improvements = to the
> trust anchor publication mechanism.
> http://forum.icann.org/lists/comments-root-zone-co= nsultation-08mar13/msg00013.html
>
> The most important is the last paragraph:
>
> : I understand that ICANN would like to include third party signatures= on
> : the root trust anchor publication web site. This would be a very goo= d
> : thing, since it would allow out-of-band update software to require a=
> : quorum of valid signatures instead of just one. This improves
> : security, since compromise of a single key does not compromise the > : whole process. It improves robustness, since signing keys will be ab= le
> : to change without breaking existing software that uses those keys fo= r
> : validation, so long as a quorum of old-enough keys remain in use. >
> Basically I want a machine-verifiable version of this:
> http://dns.icann.org/ksk= /ds19036/
>
> The risk is that the key used to sign the KSK, and the CA used to
> authenticate the key, are both single points of failure. There is no > single point of failure in the quorum-of-witnesses scheme. The keys ca= n
> all be simply self-signed since individual keys are only slightly trus= ted;
> the trust comes from agreement between several independent signatures.=
>
> Here are some more suggestions.
>
> Related to the previous risk, there are some operational and
> organizational single points of failure in the publication web site - = for
> instance it is vulnerable to DNS and BGP screwups. This can be mitigat= ed
> using a system of mirror sites.
>
> A more serious risk: the current publication scheme is vulnerable to > replay attacks. If the KSK is compromised, an attacker might be able t= o
> force a victim to download and trust an old version of the trust ancho= r
> publication document. To mitigate this the trust anchor document (or i= ts
> signatures) should have an explicit lifetime. Validators should refres= h
> their copy of the trust anchor document before it expires. They should=
> remember the most recent version they have seen and refuse to downgrad= e to
> an old version. They should probably also keep track of which DNSKEYs = have
> been retired and refuse to trust them forever more.
>
> There is perhaps an opportunity to improve on RFC 5011, in particular = to
> reduce the time to recover from a compromised KSK without pre-publishi= ng
> standby keys. If a validator sees a change in the set of KSKs, it fetc= hes
> and verifies the trust anchor document in order to authenticate the > change. This can lead to the validator immediately trusting the new KS= K
> and distrusting the old one. A rollover should take effect globally in=
> roughly the TTL of the DNSKEY RRset - two days for the root at the mom= ent.
>
> The old KSK has to remain actively used for signing the DNSKEY RRset > during the rollover for a couple of reasons: first, you seriously do n= ot
> want an attacker to be able to use a bogus DNSKEY RRset to force a
> validator to attempt a trust anchor update; second, it's desirable to = let
> the validator continue using its existing trust anchor during the upda= te
> process since that will be relatively slow.
>
> I think it makes sense to distinguish between a trust anchor refresh /=
> update, which occurs during continuous operation of the validator, and=
> which is only triggered by the age of the trust anchor document or by = a
> validated change in the DNSKEY KSKs; and trust anchor bootstrap, which=
> occurs when the validator has been offline long enough that its existi= ng
> trust anchors do not work. In normal operation, failure to validate th= e
> root should be treated as an attack or a severely broken local network= ,
> and the right reaction is not to attempt an update. Bootstrapping is > relatively risky and should only occur when the system is started or w= akes
> up after a long sleep.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at = first.
> Rough, becoming slight or moderate. Showers, rain at first. Moderate o= r good,
> occasionally poor at first.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ie= tf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.or= g/mailman/listinfo/dnsop
 --_000_A45EDA9B668744B394AB32CC561DD26Diisse_-- From paul@cypherpunks.ca Sat Apr 20 09:10:03 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C1221F89A6 for ; Sat, 20 Apr 2013 09:10:03 -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 vkT+ziluRoMY for ; Sat, 20 Apr 2013 09:10:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB6921F8991 for ; Sat, 20 Apr 2013 09:10:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZtJsx4gzpz7Ds; Sat, 20 Apr 2013 12:09:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wGdk3nwjaAZ9; Sat, 20 Apr 2013 12:09:56 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Sat, 20 Apr 2013 12:09:56 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0600A80E0F; Sat, 20 Apr 2013 12:09:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E61FE805CC; Sat, 20 Apr 2013 12:09:56 -0400 (EDT) Date: Sat, 20 Apr 2013 12:09:56 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Steve Crocker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dnsop , dnssec-deployment@dnssec-deployment.org Subject: Re: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 16:10:04 -0000 On Fri, 19 Apr 2013, Steve Crocker wrote: > If someone is paranoid about the possibility of being spoofed, he can compare the results from multiple publishers and/or rotate among the many publishers. But there's no need for the publishers to coordinate among themselves, except for the standard format, and there's no need for a formal quorum of witnesses. (I guess if someone wanted to advocate a best practice of using a quorum of witnesses, that's ok with me, but I view that as an added layer, not necessarily required.) You have solved the easy human problem. Now do the same for fully automated computers that are turned on after 10 years. There is currently one publisher (ICANN pem bundle plus static web page with certs signed by particular CA). Will that page be there in 10 years? Where will the other publications be? A few humans can figure this thing out easilly, and adapt. The problem of rolling the root key is automation. Imagine your previous DSL router was doing DNSSEC with the previous root key. Your current DSL modem dies, and you power on your old one. What will happen? Now repeat, and say that the SHA2 family was broken and SHA4 is now the standard. Your old modem talks SHA2 only. I don't think we as a group have ignored this problem - we have just not found a proper solution yet. Rolling the root key now will be pretty meaningless as a test for deployment issues in the future. And if the root zone operator wants to test their procedures, they can do so in a lab. Paul From jabley@hopcount.ca Sat Apr 20 09:16:16 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F074421F8A80 for ; Sat, 20 Apr 2013 09:16:16 -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 miy3C143k6bT for ; Sat, 20 Apr 2013 09:16:16 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3768721F8A53 for ; Sat, 20 Apr 2013 09:16:16 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b10so3381119qen.14 for ; Sat, 20 Apr 2013 09:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=UwsbMv67B69tuQZY8VR6MecdCJLputxW7PLHyb3xLes=; b=k0+y+afOU5RlBZgY+H6xu4+xKPCj/x0uPOSKOpakyK5zILt8aCxlpI9IWVSctP/Tw5 cBNz+aExdMs68DX2UYrNmj0PsO93bhlm0UlpLXucLvbVVyOZpa5I4Yy5X4olboYAWRRX oRB1xU7GGUGx/hgN+Ld1+RAJSgdZ/MnSlD8A0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UwsbMv67B69tuQZY8VR6MecdCJLputxW7PLHyb3xLes=; b=WT7SF5iTzN/xycfe3sxE5OOrKHIILZJzltHOgyi3lAQZ19oSLEUIT2bcet/d/+42Wo VN7Rm1XncelUQM9wVOHejp+gPYJ+dTMJelH/uZUcjkqfqg1necDQ4ztjU+Ng2cTdrQ16 gbsYmc0lJUtCQs0h+m5uTXSIGVBH6I28fMFhSkp/hId1VW6Bm7/EjHvRhZfq1xl3aBKp Wr8gx7Mfs/FZRC1e5T6xYevwatsjnOb3z1cQxKjv27GL9ZHGo0KERUWcPfEP/egXIgNK 3wv8KlPEGAHoVw4GTUavKDJthohiuLTnKUAAB4F7qm4WlxEduxobcgOdvq755rSTgLbP 4NjQ== X-Received: by 10.224.72.83 with SMTP id l19mr17577686qaj.63.1366474575723; Sat, 20 Apr 2013 09:16:15 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPS id h5sm22556836qai.9.2013.04.20.09.16.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Apr 2013 09:16:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Sat, 20 Apr 2013 12:16:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <437C9B86-36EB-4AC3-8ADF-3D5738EF4D79@hopcount.ca> References: To: Paul Wouters X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQn/vjU8cCE7SwQ2z0AmoZd0HsKQQQ9/TC24bCFCuSBpCCaoRdABP3JuapYeE29ilt8EGJrc Cc: Steve Crocker , dnsop , dnssec-deployment@dnssec-deployment.org Subject: Re: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 16:16:17 -0000 On 2013-04-20, at 12:09, Paul Wouters wrote: > There is currently one publisher (ICANN pem bundle plus static web = page > with certs signed by particular CA). Will that page be there in 10 = years? > Where will the other publications be? The pragmatic answer to this is that ICANN is under contract to support = that mechanism, and any successor organisation carrying out the IANA = Functions Contract would no doubt inherit the same requirement (changes = tending to involve wide technical consultation, and the likelihood of = people saying "yeah, that's a great idea, change it" seems slim). See = also the ftp URLs for the root hints file, whose locations haven't = changed since they were first published there many years ago, before = ICANN existed (or before URLs existed, in fact). I think we can assume that the data.iana.org/root-anchor/ URLs are baked = in at layer-9. Joe From jim@rfc1035.com Sat Apr 20 09:59:09 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D13421F84D1 for ; Sat, 20 Apr 2013 09:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSKXR59mLTLE for ; Sat, 20 Apr 2013 09:59:09 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id C32F921F84CE for ; Sat, 20 Apr 2013 09:59:08 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 73529CBC41F; Sat, 20 Apr 2013 17:59:07 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jim Reid In-Reply-To: Date: Sat, 20 Apr 2013 17:59:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.1503) Cc: Steve Crocker , dnsop , dnssec-deployment@dnssec-deployment.org Subject: Re: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 16:59:09 -0000 On 20 Apr 2013, at 17:09, Paul Wouters wrote: > Imagine your previous DSL router was doing DNSSEC with the previous = root key. Your current DSL modem dies, and you power on your old one. = What will happen? You go to the nearest shop and spend $20-30 on new CPE because the old = one(s) are broken. :-) > Now repeat, and say that the SHA2 family was broken and SHA4 is now = the > standard. Your old modem talks SHA2 only. >=20 > I don't think we as a group have ignored this problem - we have just = not > found a proper solution yet. I am not sure there needs to be a proper solution. Or that a one size = fits all solution is even possible or desirable. This topic is largely a = matter of implementation and/or local policy after all. Some generalised = motherhood and apple pie guidelines/advice would probably be enough: = don't hard-wire the current root KSK as a trust anchor; always design = your stuff with the assumption the root KSK must change from time to = time; provide some out of band means for your stuff to recover from a = missed key rollover; consider designing your firmware to handle changes = to the root KSK in a similar way to how it deals with a regular software = update, etc. Maybe a document along these lines is needed? We can be fairly certain that the URLs IANA publishes for the root TA = are not going to change. Though perhaps that needs to be explicitly = stated by someone. So it should be a simple matter of programming to = provide some way to slurp that stuff, check it and update the locally = held TA. Something comparable to unbound-anchor could do the job. = Suppliers of CPE -- vendor, ISP -- might even provide their own copy of = that repository in whatever format they choose so their stuff can = contact the mothership at regular intervals or after a hard reset. For = bonus points that update mechanism could use a secure out of band = channel by (say) embedding a cert or public key tied to the IP address = of the supplier's repository into the firmware. From fanf2@hermes.cam.ac.uk Sat Apr 20 10:10:02 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2A821F8B07 for ; Sat, 20 Apr 2013 10:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 eUC9MBCmRUzP for ; Sat, 20 Apr 2013 10:09:59 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 4950421F8AF7 for ; Sat, 20 Apr 2013 10:09:48 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host86-143-220-115.range86-143.btcentralplus.com ([86.143.220.115]:55491 helo=[192.168.1.66]) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1UTbIH-0006Cc-6Y (Exim 4.80_167-5a66dd3) (return-path ); Sat, 20 Apr 2013 18:09:45 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7D7B902E-D63F-4E09-A882-8F54C1E234C5@dotat.at> X-Mailer: iPhone Mail (10B144) From: Tony Finch Date: Sat, 20 Apr 2013 18:09:43 +0100 To: Paul Wouters Sender: Tony Finch Cc: Tony Finch , Steve Crocker , dnsop , "dnssec-deployment@dnssec-deployment.org" Subject: Re: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 17:10:02 -0000 On 20 Apr 2013, at 17:09, Paul Wouters wrote: >=20 > You have solved the easy human problem. Now do the same for fully > automated computers that are turned on after 10 years. You can be fairly profligate with witness signatures, since they are not goi= ng to be downloaded and checked very often, nor when you need a very quick a= nswer. Witness keys should stay in use indefinitely, until they are broken c= ryptographically or operationally. They should have a good diversity of algo= rithms and operational practices so they don't all break at once. Over time n= ew witnesses will be added to support newer algorithms. Weaker witnesses wil= l keep signing, to support old code, though new code might only use newer wi= tnesses. So when a very old validator starts up it should still have a decent chance o= f being able to get and verify the current trust anchor document. If it turn= s out that the root KSK uses an unsupported algorithm, the validator does at= least know for certain that it has no choice but to go insecure. Tony. -- f.anthony.n.finch http://dotat.at/= From paul@cypherpunks.ca Sat Apr 20 10:40:10 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E8121F8B8F for ; Sat, 20 Apr 2013 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ThMKOKBjCMm for ; Sat, 20 Apr 2013 10:40:09 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 97CD021F88EA for ; Sat, 20 Apr 2013 10:40:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZtLsy2xpfz7Ds; Sat, 20 Apr 2013 13:40:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JFDcEHxgNkF1; Sat, 20 Apr 2013 13:40:05 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Sat, 20 Apr 2013 13:40:04 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 85FA980EAF; Sat, 20 Apr 2013 13:40:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 751F2805CC; Sat, 20 Apr 2013 13:40:05 -0400 (EDT) Date: Sat, 20 Apr 2013 13:40:05 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Edward Lewis In-Reply-To: <9B0D2E87-5D93-43C0-9EE5-7B38E43920F3@neustar.biz> Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <9B0D2E87-5D93-43C0-9EE5-7B38E43920F3@neustar.biz> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 17:40:10 -0000 On Fri, 19 Apr 2013, Edward Lewis wrote: Sorry. You are right. CDS is a method for non-TLD paren-children to communicate the KSK information from child to parent. And even more important because there might be no EPP or other standarized channel. > That's fine. Don't publish CDS as a child, or ignore CDS as a parent. > > How do my customers then get the DS from our servers to their registration systems (registrars with EPP or not)? >  The state of the art is cut and paste for most.  Without a standard here, we are stuck with a lowest common > denominator situation. Now I'm confused about what you would like to see. You wrote: > My response is that the CDS should not automatically cause a change to > the DS, just marshall the data. > I am pushing to rely on a second factor (the security over the c&c > channel to the parent) to verify the request. > > I'm not comfortable with in-band scraping. I guess we could add language that states the intention of the child. If the CDS is signed by the KSK, the child agrees for the parent to update the DS. If the CDS is signed by the ZSK, the child is just "marshalling the data" and the parent should look elsewhere for the authentication of that data. This still leaves open that a compromised KSK can lead to parent DS changes, but I don't see a way around that without sacrifcing the requirement that fully automated KSK rollovers using just DNSSEC data in the zone should be possible. Paul From ed.lewis@neustar.biz Mon Apr 22 06:32:58 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17FE21F85CE for ; Mon, 22 Apr 2013 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.118 X-Spam-Level: X-Spam-Status: No, score=-102.118 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 WNWgA2u4mlpP for ; Mon, 22 Apr 2013 06:32:58 -0700 (PDT) Received: from smtp195.dfw.emailsrvr.com (smtp195.dfw.emailsrvr.com [67.192.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id D152021F85CB for ; Mon, 22 Apr 2013 06:32:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6A9413C858B; Mon, 22 Apr 2013 09:32:57 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 096F63C84FA; Mon, 22 Apr 2013 09:32:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D8C4A87-ADE3-472C-8280-77CCD135C8F1" From: Edward Lewis In-Reply-To: Date: Mon, 22 Apr 2013 09:32:55 -0400 Message-Id: <5062D61B-BB1A-4289-B16E-B9CA6AAA4025@neustar.biz> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <9B0D2E87-5D93-43C0-9EE5-7B38E43920F3@neustar.biz> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:32:58 -0000 --Apple-Mail=_3D8C4A87-ADE3-472C-8280-77CCD135C8F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 20, 2013, at 13:40, Paul Wouters wrote: >=20 > Now I'm confused about what you would like to see. You wrote: >=20 >> My response is that the CDS should not automatically cause a change = to >> the DS, just marshall the data. >> I am pushing to rely on a second factor (the security over the c&c >> channel to the parent) to verify the request. >> I'm not comfortable with in-band scraping. >=20 > I guess we could add language that states the intention of the child. First, some use cases, written from the child operator's perspective: I want to add a DS record for a key that is not yet published. I want to delete a DS record for a key that has never been published. = (*) I want to add a DS recrord for a key that is in use. I want to delete a DS record for a key that is in use. I want to add DS records for hashes not previously supported. I want to add DS records for hashes I am moving away from. ...and others in the "I want to add/delete" category. > If the CDS is signed by the KSK, the child agrees for the parent to = update the DS. >=20 > If the CDS is signed by the ZSK, the child is just "marshalling the = data" and the > parent should look elsewhere for the authentication of that data. We really do need to drop the KSK and ZSK terminology because there are = Common Signing Keys coming "back" in vogue. The factor is whether a key = is a SEP or not. Recall that in the validation and signing engines, the = SEP bit is not significant, it is there for the convenience of key = management tools. What if I use a key in the role of a ZSK and then decide to convert it = into an SEP? Today I can do this by just adding a DS record for the = key. But if we start with rules on what roles can sign what record sets = and in what ways, I'd have to flip the SEP bit - which then changes the = identity of the key. (Same issue as in revoking keys a la RFC 5011.) > This still leaves open that a compromised KSK can lead to parent DS > changes, but I don't see a way around that without sacrifcing the > requirement that fully automated KSK rollovers using just DNSSEC data > in the zone should be possible. I think you can close that vulnerability by relying on "some other = factor" in the key change process. Where is the requirement for "fully automated KSK rollovers using just = DNSSEC data" come from? I don't mean a document citation, I mean the = basis in reality? I can see the allure but I don't think it is wise. What I have in mind - and this isn't a "has to be this way" - is this = kind of a specification. 1. A definition of the CDS record set that conveys the hashes from the = child to the parent or a means for the parent to get keys if they so = desire. What I don't have a solution for is supporting DS records of = unpublished DNSKEYs in zones were the parent wants the keys. Included = would be ways to specify hash functions that the parent hasn't = implemented, etc., i.e., the ability for the child to be totally = autonomous in the management of their zone. I am not overly aggressive = parental actions, but there should be support for "true" delegations of = authority. 2. =46rom the child side, when a child publishes CDS record(s), a = statement of what that means. In some sense it will be dependent on = step 1. My preference is that a CDS record is an incremental change = request of the parent, others want the set to be the desired state at = the end of all operations. Either one is possible, my preference is = just "that" at this point. (As far as what key signs the see my previous words.) What's to be left out of the "spec" and addressed in words is that the = child might have to alert the parent. 3. Again from the child side, when does it withdraw the CDS record(s) = (set). Could be that the child keeps it there until the parent held DS = set matches (polling) or some other event happens. I'd default to a = zone polling the parent over event driven because removal of records is = the forgotten step in most operations. 4. =46rom the parent, words on detection of the record(s) (set), words = on how to perform the operations, and then a discussion on letting the = child know. Here's where I see a lot of pitfalls in IETF document = processing. If the document specifies one way to do detection or = another, this will be burned into the RFC. =46rom then on, all those = following the RFC would have to deal with compliance questions...so even = if I just want to make use of what is in part 1, I'll have to address = why part 4 is or is not applicable. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_3D8C4A87-ADE3-472C-8280-77CCD135C8F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Now I'm = confused about what you would like to see.  You = wrote:

My response is that the CDS = should not automatically cause a change to
the DS, just marshall the = data.
I am pushing to rely on = a second factor (the security over the = c&c
channel to the parent) = to verify the request.
I'm not = comfortable with in-band scraping.

I guess we could = add language that states the intention of the = child.

First, some use cases, = written from the child operator's = perspective:

I want to add a DS record for a = key that is not yet published.
I want to delete a DS record = for a key that has never been published. (*)
I want to add a = DS recrord for a key that is in use.
I want to delete a DS = record for a key that is in use.
I want to add DS records for = hashes not previously supported.
I want to add DS records for = hashes I am moving away from.
...and others in the "I want to = add/delete" category.

If the CDS is signed by the KSK, the child agrees for = the parent to update the DS.

If the CDS is signed by the ZSK, the = child is just "marshalling the data" and the
parent should look = elsewhere for the authentication of that = data.

We really do need to = drop the KSK and ZSK terminology because there are Common Signing Keys = coming "back" in vogue.  The factor is whether a key is a SEP or = not.  Recall that in the validation and signing engines, the SEP = bit is not significant, it is there for the convenience of key = management tools.

What if I use a key in the = role of a ZSK and then decide to convert it into an SEP?  Today I = can do this by just adding a DS record for the key.  But if we = start with rules on what roles can sign what record sets and in what = ways, I'd have to flip the SEP bit - which then changes the identity of = the key.  (Same issue as in revoking keys a la RFC = 5011.)

This still = leaves open that a compromised KSK can lead to parent DS
changes, but = I don't see a way around that without sacrifcing the
requirement that = fully automated KSK rollovers using just DNSSEC data
in the zone = should be possible.

I think = you can close that vulnerability by relying on "some other factor" in = the key change process.

Where is the requirement for = "fully automated KSK rollovers using just DNSSEC data" come from? =  I don't mean a document citation, I mean the basis in reality? =  I can see the allure but I don't think it is = wise.

What  I have in mind - and this = isn't a "has to be this way" - is this kind of a = specification.

1. A definition of the CDS = record set that conveys the hashes from the child to the parent or a = means for the parent to get keys if they so desire.  What I don't = have a solution for is supporting DS records of unpublished DNSKEYs in = zones were the parent wants the keys.  Included would be ways to = specify hash functions that the parent hasn't implemented, etc., i.e., = the ability for the child to be totally autonomous in the management of = their zone.  I am not overly aggressive parental actions, but there = should be support for "true" delegations of = authority.

2. =46rom the child side, when a = child publishes CDS record(s), a statement of what that means.  In = some sense it will be dependent on step 1.  My preference is that a = CDS record is an incremental change request of the parent, others want = the set to be the desired state at the end of all operations. =  Either one is possible, my preference is just "that" at this = point.

(As far as what key signs the see my = previous words.)

What's to be left out of the = "spec" and addressed in words is that the child might have to alert the = parent.

3. Again from the child side, when does = it withdraw the CDS record(s) (set).  Could be that the child keeps = it there until the parent held DS set matches (polling) or some other = event happens.  I'd default to a zone polling the parent over event = driven because removal of records is the forgotten step in most = operations.

4. =46rom the parent, words on = detection of the record(s) (set), words on how to perform the = operations, and then a discussion on letting the child know. =  Here's where I see a lot of pitfalls in IETF document processing. =  If the document specifies one way to do detection or another, this = will be burned into the RFC.  =46rom then on, all those following = the RFC would have to deal with compliance questions...so even if I just = want to make use of what is in part 1, I'll have to address why part 4 = is or is not applicable.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_3D8C4A87-ADE3-472C-8280-77CCD135C8F1-- From cet1@hermes.cam.ac.uk Mon Apr 22 10:50:40 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28721F934D for ; Mon, 22 Apr 2013 10:50:40 -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 Tr0XrM4kaLih for ; Mon, 22 Apr 2013 10:50:39 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 6644821E8044 for ; Mon, 22 Apr 2013 10:50:39 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41673) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1UUKsw-0006Tv-gW (Exim 4.80_167-5a66dd3) (return-path ); Mon, 22 Apr 2013 18:50:38 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1UUKsw-0002R3-3q (Exim 4.72) (return-path ); Mon, 22 Apr 2013 18:50:38 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 22 Apr 2013 18:50:38 +0100 Date: 22 Apr 2013 18:50:38 +0100 From: Chris Thompson To: Edward Lewis Message-ID: In-Reply-To: <5062D61B-BB1A-4289-B16E-B9CA6AAA4025@neustar.biz> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <9B0D2E87-5D93-43C0-9EE5-7B38E43920F3@neustar.biz> <5062D61B-BB1A-4289-B16E-B9CA6AAA4025@neustar.biz> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 17:50:40 -0000 On Apr 22 2013, Edward Lewis wrote: >We really do need to drop the KSK and ZSK terminology because there are >Common Signing Keys coming "back" in vogue. The factor is whether a key >is a SEP or not. Recall that in the validation and signing engines, >the SEP bit is not significant, it is there for the convenience of key >management tools. I was extremely pleased to see that draft-kumari-ogud-dnsop-cds-01 dropped all mention of KSK and ZSK (well, almost - there is a reference to KSK in the introduction). It may be that there is still too much talk about the SEP bit. The essence of the previous requirement that CDS RRsets were to be signed with a KSK is much better captured by the current text: The CDS record MUST be at the zone apex, and MUST be signed with a key that is represented in the current DNSKEY and DS RRset's. If these conditions are not met the CDS record MUST be ignored. That is, the chain of trust used by the parent to validate a CDS is restricted to be of length 1. That is all it knows on earth, and all it needs to know (with apologies to John Keats). -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From ed.lewis@neustar.biz Mon Apr 22 12:15:57 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40B111E80E2 for ; Mon, 22 Apr 2013 12:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cyAygozOjDyn for ; Mon, 22 Apr 2013 12:15:56 -0700 (PDT) Received: from smtp101.ord1c.emailsrvr.com (smtp101.ord1c.emailsrvr.com [108.166.43.101]) by ietfa.amsl.com (Postfix) with ESMTP id D7A3B11E80D9 for ; Mon, 22 Apr 2013 12:15:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 77D1A1B0109; Mon, 22 Apr 2013 15:15:55 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 3CE231B0140; Mon, 22 Apr 2013 15:15:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_EDF15AF7-E5E3-4E21-8A22-50B093548B2F" From: Edward Lewis In-Reply-To: Date: Mon, 22 Apr 2013 15:15:54 -0400 Message-Id: <527953A5-09C8-4A91-B28F-155788450868@neustar.biz> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <9B0D2E87-5D93-43C0-9EE5-7B38E43920F3@neustar.biz> <5062D61B-BB1A-4289-B16E-B9CA6AAA4025@neustar.biz> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 19:15:57 -0000 --Apple-Mail=_EDF15AF7-E5E3-4E21-8A22-50B093548B2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 22, 2013, at 13:50, Chris Thompson wrote: > On Apr 22 2013, Edward Lewis wrote: >=20 >> We really do need to drop the KSK and ZSK terminology because there = are >> Common Signing Keys coming "back" in vogue. The factor is whether a = key >> is a SEP or not. Recall that in the validation and signing engines, >> the SEP bit is not significant, it is there for the convenience of = key >> management tools. >=20 > I was extremely pleased to see that draft-kumari-ogud-dnsop-cds-01 = dropped > all mention of KSK and ZSK (well, almost - there is a reference to KSK = in > the introduction). It may be that there is still too much talk about = the > SEP bit. >=20 > The essence of the previous requirement that CDS RRsets were to be = signed > with a KSK is much better captured by the current text: >=20 > The CDS record MUST be at the zone apex, and MUST be signed with a > key that is represented in the current DNSKEY and DS RRset's. If > these conditions are not met the CDS record MUST be ignored. What confuses me is that signing in DNSSEC is not done on a record by = record basis but on a set basis. Meaning, you can't "ignore" a record = within a set. For the use case of wanting to publish a DS record for an = unpublished DNSKEY, how will this work? In this case, I can sign the = set with an existing DNSKEY that is represented in the DS set. With = that, all CDS records would be authenticated. Perhaps this is just a = wording issue, but the alternative to that is that none of the CDS set = is valid. Requiring a CDS to be signed by a key that is present and signs the = DNSKEY set as well as being referenced in the DS set before it is = accepted as a request of the child is different from requiring the set = be signed by a key with a KSK designation or even an SEP bit turned on. = The former is setting up rules "above" the normal validation of DNSSEC = data and therefore can be set into a code path reserved for a special = function. The latter (placing more requirements on what key can be used = to validate data) represents a change to the basic validation rules in = DNSSEC - that is something I want to avoid because it would open up a = new set of issues that we've not explored. (Well, actually, in the = early days, we toyed with key role-based rules for authentication and = the models failed. If anyone reads the ancient texts, there's a talk = about key strength, which was part of the failed experiments.) I would accept that the parent ought to be aware of what key signs the = CDS set and could use that information in determining the authenticity = and authorization of the request. In some use cases this could be = acceptable to me (said in the sense that I'm not sure yet.) However, in = other cases, I would want stronger checks to take place. Note that I am not saying that it would be bad to define a key change = where the parent only needs the CDS set to be signed by (ultimately) a = key represented in the existing DS set. (I'm using multiple negatives = here on purpose "not saying...it would be bad".) I think that such a = practice can co-exist with stronger practices, like those requiring out = of band notifications and confirmations. I want there to be the = possibility of more than one model for authentication and authorization, = based on the existence of a "standard" CDS. I don't want "my way" to be = the one, I just want to make sure that I can handle multiple ways with a = common data representation. In my code, I'd want to sign the CDS set like it was an A record set. = For zones that need the signer to be in the DS set too, that would be a = special case but one that could be triggered automatically. Somehow, = perhaps in the CDS record itself ("request for SEP signature bit"). > That is, the chain of trust used by the parent to validate a CDS is > restricted to be of length 1. That is all it knows on earth, and all > it needs to know (with apologies to John Keats). I really don't think this is important. For example you might have a = registrant who "owns" a name, outsource it's web and dns operations to a = third party, register the name via a reseller (that provides a WhoIs = proxy service to hide the registrant) who then uses a registrar that = talks to a registry to get a name into TLD that is run by a backend = operator. Having a trust chain of length 1 in DNSSEC is a false sense = of "closeness" here. We talk of trying to prevent a false sense of = security at times. In sum, think of the way the SEP bit was born. As a help to tools that = set up a zone. Not as a factor in normal line DNSSEC processing, = something not to be used or assumed by the validators. For the CDS, the = special processing line is tied to how you provision the parent than how = data is validated. For this I'd make sure the recommendations and/or = rules in the document take steps to enforce the nature of the SEP bit = and not lead us into confusion. And, again, I want to be able to deal = with multiple back-end procedures for finding, accepting, and processing = the request that a CDS represents. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_EDF15AF7-E5E3-4E21-8A22-50B093548B2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Apr 22 2013, Edward Lewis = wrote:

We really do need to drop the = KSK and ZSK terminology because there are
Common Signing Keys coming "back" in vogue.  The = factor is whether a key
is a = SEP or not.  Recall that in the validation and signing = engines,
the SEP bit is not = significant, it is there for the convenience of = key
management = tools.

I was extremely pleased to see that = draft-kumari-ogud-dnsop-cds-01 dropped
all mention of KSK and ZSK = (well, almost - there is a reference to KSK in
the introduction). It = may be that there is still too much talk about the
SEP = bit.

The essence of the previous requirement that CDS RRsets were = to be signed
with a KSK is much better captured by the current = text:

 The CDS record MUST be at the zone apex, and MUST be = signed with a
 key that is represented in the current DNSKEY = and DS RRset's.  If
 these conditions are not met the CDS = record MUST be ignored.

What = confuses me is that signing in DNSSEC is not done on a record by record = basis but on a set basis.  Meaning, you can't "ignore" a record = within a set.  For the use case of wanting to publish a DS record = for an unpublished DNSKEY, how will this work?  In this case, I can = sign the set with an existing DNSKEY that is represented in the DS set. =  With that, all CDS records would be authenticated.  Perhaps = this is just a wording issue, but the alternative to that is that none = of the CDS set is valid.

Requiring a CDS to be = signed by a key that is present and signs the DNSKEY set as well as = being referenced in the DS set before it is accepted as a request of the = child is different from requiring the set be signed by a key with a KSK = designation or even an SEP bit turned on.  The former is setting up = rules "above" the normal validation of DNSSEC data and therefore can be = set into a code path reserved for a special function.  The latter = (placing more requirements on what key can be used to validate data) = represents a change to the basic validation rules in DNSSEC - that is = something I want to avoid because it would open up a new set of issues = that we've not explored.  (Well, actually, in the early days, we = toyed with key role-based rules for authentication and the models = failed.  If anyone reads the ancient texts, there's a talk about = key strength, which was part of the failed = experiments.)

I would accept that the parent = ought to be aware of what key signs the CDS set and could use that = information in determining the authenticity and authorization of the = request.  In some use cases this could be acceptable to me (said in = the sense that I'm not sure yet.)  However, in other cases, I would = want stronger checks to take place.

Note that I = am not saying that it would be bad to define a key change where the = parent only needs the CDS set to be signed by (ultimately) a key = represented in the existing DS set.  (I'm using multiple negatives = here on purpose "not saying...it would be bad".)  I think that such = a practice can co-exist with stronger practices, like those requiring = out of band notifications and confirmations.  I want there to be = the possibility of more than one model for authentication and = authorization, based on the existence of a "standard" CDS.  I don't = want "my way" to be the one, I just want to make sure that I can handle = multiple ways with a common data = representation.

In my code, I'd want to sign = the CDS set like it was an A record set.  For zones that need the = signer to be in the DS set too, that would be a special case but one = that could be triggered automatically.  Somehow, perhaps in the CDS = record itself ("request for SEP signature = bit").

That is, the chain = of trust used by the parent to validate a CDS is
restricted to be of = length 1. That is all it knows on earth, and all
it needs to know = (with apologies to John = Keats).

I really don't = think this is important.  For example you might have a registrant = who "owns" a name, outsource it's web and dns operations to a third = party, register the name via a reseller (that provides a WhoIs proxy = service to hide the registrant) who then uses a registrar that talks to = a registry to get a name into TLD that is run by a backend operator. =  Having a trust chain of length 1 in DNSSEC is a false sense of = "closeness" here.  We talk of trying to prevent a false sense of = security at times.

In sum, think of the way the = SEP bit was born.  As a help to tools that set up a zone.  Not = as a factor in normal line DNSSEC processing, something not to be used = or assumed by the validators.  For the CDS, the special processing = line is tied to how you provision the parent than how data is validated. =  For this I'd make sure the recommendations and/or rules in the = document take steps to enforce the nature of the SEP bit and not lead us = into confusion.  And, again, I want to be able to deal with = multiple back-end procedures for finding, accepting, and processing the = request that a CDS represents.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_EDF15AF7-E5E3-4E21-8A22-50B093548B2F-- From wjhns1@hardakers.net Mon Apr 22 13:15:50 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7717D21E80D8 for ; Mon, 22 Apr 2013 13:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 UbqJqQrT1-4n for ; Mon, 22 Apr 2013 13:15:49 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 10CC521E804E for ; Mon, 22 Apr 2013 13:15:49 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id A27BF28BE3; Mon, 22 Apr 2013 13:15:45 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> Date: Mon, 22 Apr 2013 13:15:44 -0700 In-Reply-To: <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> (Edward Lewis's message of "Fri, 19 Apr 2013 13:22:43 -0400") Message-ID: <0l8v4afhjj.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:15:50 -0000 Edward Lewis writes: > My response is that the CDS should not automatically cause a change to the DS, just marshall the data. > > I am pushing to rely on a second factor (the security over the c&c > channel to the parent) to verify the request. Nothing is preventing that from happening too. IE, there is nothing in the existing document that prevents a registar or other parent from putting this on their webpage: Update the DS record when (pick one): [ ] Ever a properly signed CDS record exists [ ] Ever a properly signed CDS record exists and I click an OK button here [ ] Never. I enjoy the ctrl-v experience. There is still no point in mandating that an auto-accept can't happen for those that want to. There is no point in pushing that option into the spec itself; the parent already has a database of options the child wants. The parent already has the ability to require a user to push an OK button if it wants it. So does the child (assuming the parent has a radio-dialog as indicated above). There is nothing preventing a CDS record from doing both automated marshaling and accept *or* just automated marshaling. -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Mon Apr 22 13:19:20 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E955221F8A2A for ; Mon, 22 Apr 2013 13:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 R+1zV4VZzNGG for ; Mon, 22 Apr 2013 13:19:19 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id D1EA921F8AF8 for ; Mon, 22 Apr 2013 13:19:14 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id 5374B28C69; Mon, 22 Apr 2013 13:19:14 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> Date: Mon, 22 Apr 2013 13:19:07 -0700 In-Reply-To: <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> (Edward Lewis's message of "Fri, 19 Apr 2013 11:29:20 -0400") Message-ID: <0l4neyfhdw.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:19:20 -0000 Edward Lewis writes: > I am unconvinced that the special signing rules mentioned in the draft > are warranted and is one of the main reasons I am not a supporter of > the draft. I have a fundamental objection to that specific provision. > Yes, even understanding the rationale for it, I don't buy the reason. For what it's worth: I'm sort of on the fence when it comes to needing to sign with the KSK. There are so very very few key-split owners out there that it's not a huge market for them, and I doubt any of them will want to do CDS anyway to their parent. So, if it didn't change the what-must-sign it rule, would you come to support it? -- Wes Hardaker Parsons From wjhns1@hardakers.net Mon Apr 22 14:17:25 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55A21E804E for ; Mon, 22 Apr 2013 14:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 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 da9azU+E6ly4 for ; Mon, 22 Apr 2013 14:17:24 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F39B21E804D for ; Mon, 22 Apr 2013 14:17:24 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id CB53023859; Mon, 22 Apr 2013 14:17:22 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> <0l4neyfhdw.fsf@wjh.hardakers.net> Date: Mon, 22 Apr 2013 14:17:21 -0700 In-Reply-To: <0l4neyfhdw.fsf@wjh.hardakers.net> (Wes Hardaker's message of "Mon, 22 Apr 2013 13:19:07 -0700") Message-ID: <0lobd61d0e.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG , Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:17:25 -0000 Wes Hardaker writes: > For what it's worth: I'm sort of on the fence when it comes to needing > to sign with the KSK. There are so very very few key-split owners out > there that it's not a huge market for them, and I doubt any of them will > want to do CDS anyway to their parent. FYI: I meant to mention that there is a significant number of operators that do actually protect their keys with different levels of protection and keep their KSKs in a "better vault". Those folks might be a bit more perturbed if a ZSK could publish a new KSK. And there is more than a single-hand-count of them, unlike the ZSK/KSK ownership split. And yes, anywhere I said "KSK" you should read it as "key with the SEP bit set" -- Wes Hardaker Parsons From jabley@hopcount.ca Mon Apr 22 14:19:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA6F21E803D for ; Mon, 22 Apr 2013 14:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 71YnwHQ-26hU for ; Mon, 22 Apr 2013 14:19:45 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17721F902A for ; Mon, 22 Apr 2013 14:19:45 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id g10so3843071pdj.34 for ; Mon, 22 Apr 2013 14:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=leVGZY5Ave4nTCfZbau+3G/ITlMtf6BukTLz4UlMC0M=; b=gwf9NZzyu10NGjyVsO1YoPPh67++jLxjRIuXPZDairmdERyWGKieH7cQDg4SEfSZsF GWQ2vqU2oZYQFqixYYWzGnWI+eLXZDoFzSWHmYpTJgg/ejzLIbcdmUR7FuwBYu1sdGT2 5XvPaAZTLxh67oVqTn33o1ffrl6Hz9IrmXSHg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=leVGZY5Ave4nTCfZbau+3G/ITlMtf6BukTLz4UlMC0M=; b=dqQ2erh/jd5aivncB2gFrJoEJf7y9ekwIDShF5+5VjiPhCWybVkth+d+KJBdJKdHLo MFA6ldHLh4zbPHdAxrcCikBeA+TfUcyWKxvVXep0M+TgRzfdMbDfmWyjFatQK5AGGo2+ jEBBnztWlYh6qlwz8gy1JB4H8D1Ez0XGOEGYBi94k53XCAvFNyvdusIwWbg5DDws6ove kEsNDmNRbWRNAJkFJvzuvYGzPPyyia48k5LHobr214oZkFbQUibA5k1sf/msqCuVOTpI Qw/Hhkq02It6NpHEti31O4FYphH435Wzcy4k41MFHWQUBvHlc0InWWVpDyt1zZPPIzf7 Ro2A== X-Received: by 10.66.248.68 with SMTP id yk4mr8535257pac.137.1366665579681; Mon, 22 Apr 2013 14:19:39 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:6d2e:8640:20b5:ce74? ([2001:4900:1042:100:6d2e:8640:20b5:ce74]) by mx.google.com with ESMTPS id p5sm11697762pbl.17.2013.04.22.14.19.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 14:19:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <0lobd61d0e.fsf@wjh.hardakers.net> Date: Mon, 22 Apr 2013 17:19:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> <0l4neyfhdw.fsf@wjh.hardakers.net> <0lobd61d0e.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnxIAyH7Teadhzl/n6j+sOIqih7k1sOQsYQduaijuztBoZDqXYMQAaElGRx3gdMhlUGXEdj Cc: IETF DNSOP WG , Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:19:46 -0000 On 2013-04-22, at 17:17, Wes Hardaker wrote: > Wes Hardaker writes: >=20 >> For what it's worth: I'm sort of on the fence when it comes to = needing >> to sign with the KSK. There are so very very few key-split owners = out >> there that it's not a huge market for them, and I doubt any of them = will >> want to do CDS anyway to their parent. >=20 > FYI: I meant to mention that there is a significant number of = operators > that do actually protect their keys with different levels of = protection > and keep their KSKs in a "better vault". That's interesting. Can you cite examples? The only example I know of is the root zone, which is weird and special = for a variety of non-technical reasons. Last time I looked neither the = BIND9 nor OpenDNSSEC toolchains supported offline-KSK operations without = a lot of hackery. Joe From dougb@dougbarton.us Mon Apr 22 14:41:36 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C587421E809C for ; Mon, 22 Apr 2013 14:41:36 -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 OliWKFoCFJFf for ; Mon, 22 Apr 2013 14:41:35 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id C2F9F21E803D for ; Mon, 22 Apr 2013 14:41:35 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:21a8:5a3c:675:16e9] (unknown [IPv6:2001:470:d:5e7:21a8:5a3c:675:16e9]) by dougbarton.us (Postfix) with ESMTPSA id 71CF722B78 for ; Mon, 22 Apr 2013 21:41:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366666895; bh=dEwJzufpJ6mtNxyitBGuvDkLhvzzu5VxfypEM/02m7w=; h=Date:From:To:Subject:References:In-Reply-To; b=sXguva0CxAeWof2Lk/97EmkHMn3khFxWt1pquzJzV4C9goNwPZJH+cziEgXtoUPrw T0S6I/ZLXEfcq5MCpDt4y6v8TwfNwooYbzVXTGx5uGzetpWbp2/BE0lFtOFYA/18Vf eaQl+DiF7YbsXMyJEt7cT7DiLbQkUBjXbU+Kmuu4= Message-ID: <5175AE8F.1090803@dougbarton.us> Date: Mon, 22 Apr 2013 14:41:35 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsop@ietf.org References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> <0l4neyfhdw.fsf@wjh.hardakers.net> <0lobd61d0e.fsf@wjh.hardakers.net> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:41:36 -0000 On 04/22/2013 02:19 PM, Joe Abley wrote: > > On 2013-04-22, at 17:17, Wes Hardaker wrote: > >> Wes Hardaker writes: >> >>> For what it's worth: I'm sort of on the fence when it comes to needing >>> to sign with the KSK. There are so very very few key-split owners out >>> there that it's not a huge market for them, and I doubt any of them will >>> want to do CDS anyway to their parent. >> >> FYI: I meant to mention that there is a significant number of operators >> that do actually protect their keys with different levels of protection >> and keep their KSKs in a "better vault". > > That's interesting. Can you cite examples? > > The only example I know of is the root zone, which is weird and special for a variety of non-technical reasons. Last time I looked neither the BIND9 nor OpenDNSSEC toolchains supported offline-KSK operations without a lot of hackery. Various TLDs discussed their plans to take similar steps at various points in the past. There is no reason to believe that other sites (particularly large financials) wouldn't be doing the same. That said, I don't see any reason to introduce "ZSK can validate a CDS record," and lots of reasons to require the KSK(s) to do so. If off-line KSK users can't use CDS to do their thing, I'm sure they would consider that an acceptable compromise. Doug From warren@kumari.net Mon Apr 22 14:48:27 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782D921F896B for ; Mon, 22 Apr 2013 14:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Knu3D-nkLk2u for ; Mon, 22 Apr 2013 14:48:27 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9A521F87B1 for ; Mon, 22 Apr 2013 14:48:26 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 7738D1B40244; Mon, 22 Apr 2013 17:48:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <5175AE8F.1090803@dougbarton.us> Date: Mon, 22 Apr 2013 17:48:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> <0l4neyfhdw.fsf@wjh.hardakers.net> <0lobd61d0e.fsf@wjh.hardakers.net> <5175AE8F.1090803@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1503) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 21:48:27 -0000 On Apr 22, 2013, at 5:41 PM, Doug Barton wrote: > On 04/22/2013 02:19 PM, Joe Abley wrote: >>=20 >> On 2013-04-22, at 17:17, Wes Hardaker wrote: >>=20 >>> Wes Hardaker writes: >>>=20 >>>> For what it's worth: I'm sort of on the fence when it comes to = needing >>>> to sign with the KSK. There are so very very few key-split owners = out >>>> there that it's not a huge market for them, and I doubt any of them = will >>>> want to do CDS anyway to their parent. >>>=20 >>> FYI: I meant to mention that there is a significant number of = operators >>> that do actually protect their keys with different levels of = protection >>> and keep their KSKs in a "better vault". >>=20 >> That's interesting. Can you cite examples? >>=20 >> The only example I know of is the root zone, which is weird and = special for a variety of non-technical reasons. Last time I looked = neither the BIND9 nor OpenDNSSEC toolchains supported offline-KSK = operations without a lot of hackery. >=20 > Various TLDs discussed their plans to take similar steps at various = points in the past. There is no reason to believe that other sites = (particularly large financials) wouldn't be doing the same. >=20 > That said, I don't see any reason to introduce "ZSK can validate a CDS = record," and lots of reasons to require the KSK(s) to do so. If off-line = KSK users can't use CDS to do their thing, I'm sure they would consider = that an acceptable compromise. Um, I'm probably missing something obvious here, but you cannot use CDS = to enroll in DNSSEC. This means that you'll have to use the original = out-of-band system -- what if we extend Wes's radio buttons to include = ZSK / KSK[0]? Update the DS record when (pick one): [ ] Ever a properly signed CDS record exists [ ] Ever a properly signed CDS record exists and I click an OK = button here [ ] Never. I enjoy the ctrl-v experience. =20 Require that this is signed with the KSK? [] Yes, I have separate process for my keys. [] Nope, they all live on the same filesystem. If someone gets one, = they have the other. Obviously the parent now has more state (and the child's logic is a = little trickier), but... W [0]: s/KSK/a key with the SEP bit set/G >=20 > Doug >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --- Schizophrenia beats being alone. From paul@nohats.ca Mon Apr 22 16:54:02 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9974E21F9457 for ; Mon, 22 Apr 2013 16:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 9i9SrjBM9O44 for ; Mon, 22 Apr 2013 16:54:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0609021F9452 for ; Mon, 22 Apr 2013 16:54:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zvl4K3k5Zz9YX; Mon, 22 Apr 2013 19:53:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id egfVyuKbR-oD; Mon, 22 Apr 2013 19:53:52 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 22 Apr 2013 19:53:51 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id BA08580EC7; Mon, 22 Apr 2013 19:53:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AACAF805CC; Mon, 22 Apr 2013 19:53:51 -0400 (EDT) Date: Mon, 22 Apr 2013 19:53:51 -0400 (EDT) From: Paul Wouters To: Warren Kumari In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> <0l4neyfhdw.fsf@wjh.hardakers.net> <0lobd61d0e.fsf@wjh.hardakers.net> <5175AE8F.1090803@dougbarton.us> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 23:54:02 -0000 On Mon, 22 Apr 2013, Warren Kumari wrote: > Um, I'm probably missing something obvious here, but you cannot use CDS to enroll in DNSSEC. This means that you'll have to use the original out-of-band system -- what if we extend Wes's radio buttons to include ZSK / KSK[0]? > > Update the DS record when (pick one): > [ ] Ever a properly signed CDS record exists > [ ] Ever a properly signed CDS record exists and I click an OK button here > [ ] Never. I enjoy the ctrl-v experience. > > Require that this is signed with the KSK? > [] Yes, I have separate process for my keys. > [] Nope, they all live on the same filesystem. If someone gets one, they have the other. > > Obviously the parent now has more state (and the child's logic is a little trickier), but... You are making keys without the SEP bit an indirect Secure Entry Point. They become their own boss. In such a case, you might as well give that key the SEP bit (and not ruin the meaning of the bit for others) Paul From ed.lewis@neustar.biz Tue Apr 23 07:21:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71CA21F941D for ; Tue, 23 Apr 2013 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 LCYbLxJ+59-9 for ; Tue, 23 Apr 2013 07:21:37 -0700 (PDT) Received: from smtp133.ord.emailsrvr.com (smtp133.ord.emailsrvr.com [173.203.6.133]) by ietfa.amsl.com (Postfix) with ESMTP id 83B2021F9418 for ; Tue, 23 Apr 2013 07:21:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 17940198100; Tue, 23 Apr 2013 10:21:37 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id D04AC1980E7; Tue, 23 Apr 2013 10:21:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_95DBB78D-4A00-4602-AEA1-8A9C24023DFB" From: Edward Lewis In-Reply-To: <0l8v4afhjj.fsf@wjh.hardakers.net> Date: Tue, 23 Apr 2013 10:21:36 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 14:21:39 -0000 --Apple-Mail=_95DBB78D-4A00-4602-AEA1-8A9C24023DFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm going to attempt to reply to a few messages in one. On Apr 22, 2013, at 16:15, Wes Hardaker wrote: > There is nothing preventing a CDS record from doing both automated > marshaling and accept *or* just automated marshaling. I agree - in the sense that the "science behind it" allows for one = marshaling mechanism to be used different ways. What I am leery of is that once an RFC is published saying "here's how = you marshall it" and "here's how the data transfer works" the perception = is that to "do" CDS at all you have to both use the record and do it = that way. I speak from the experience of answering RFPs that ask for = comments about compliance with a laundry list of RFCs. Buyers (RFP = issuers) rarely show that they've read the RFCs by referencing only the = applicable sections to the bid, and commonly an RFP writer will copy = another RFP lock, stock and barrel when it comes to things like = technical details. So, my "gating requirement" for the proposal is that the document does = it's best to say "here's a good marshaling data structure" and separably = "here's one way to use it" and preferably "here's another way to use = it." This gating requirement is strictly a "how it is written" issue. And, I = do think it is very important that the document is very clear so that = when it comes to RFP or compliance or even audit time, = legal/contractural issues are minimized. On Apr 22, 2013, at 16:19, Wes Hardaker wrote: > So, if it didn't change the what-must-sign it rule, would you come to > support it? It is not so simple. In one of my long-winded, rambling, stream of = consciousness messages I suggested that there be no change to "how it is = signed" and "how it is validated" rules. Special rules can be written = for the provisioning system - an yes, the signer has to know to support = that. I firmly believe that a validator (as described in 4033-4035) should = have to be altered for the CDS proposal. But I have far less of an = objection to having the element that accepts the CDS from the child = having special rules - mostly because these do not exist today, there's = no code to retrofit, no backwards compatibility concerns. On Apr 22, 2013, at 17:41, Doug Barton wrote: > On 04/22/2013 02:19 PM, Joe Abley wrote: >>=20 >> On 2013-04-22, at 17:17, Wes Hardaker wrote: >>=20 >>> Wes Hardaker writes: >>>=20 >>> FYI: I meant to mention that there is a significant number of = operators >>> that do actually protect their keys with different levels of = protection >>> and keep their KSKs in a "better vault". >>=20 >> That's interesting. Can you cite examples? >>=20 >> The only example I know of is the root zone, which is weird and = special for a variety of non-technical reasons. Last time I looked = neither the BIND9 nor OpenDNSSEC toolchains supported offline-KSK = operations without a lot of hackery. >=20 > Various TLDs discussed their plans to take similar steps at various = points in the past. There is no reason to believe that other sites = (particularly large financials) wouldn't be doing the same. >=20 > That said, I don't see any reason to introduce "ZSK can validate a CDS = record," and lots of reasons to require the KSK(s) to do so. If off-line = KSK users can't use CDS to do their thing, I'm sure they would consider = that an acceptable compromise. Back in the day, (meaning in the late 90's before the first workshops) = we (Olafur, Brian, Russ and I) toyed with many ways to do DNSSEC. One = was to have off-line keys like KSKs (well before we made the split in = the workshops) and to have on-line keys like ZSKs and denote them with = "key strength" bits. The idea was that we'd have a protected key for = data that needed high assurance and a vulnerable key for data that = needed convenience. We quickly realized that this was non-sense as "a = chain is only as strong as it's weakest link." In normal operations it = just doesn't make sense to split the key management. Now, Joe is right. The root zone is a special case. While "weird" is a = flippant word to use here, it seriously deserves a different treatment - = and the root zone gets that treatment. What I am saying is, if there are cases of someone thinking that it is = worth the time to split KSK and ZSK, I'd urge them to reconsider. It's = not terrible but it is over engineering. I'm not inclined to "optimize" = for such an use case. I'm for choice in how to operate. But there are = limits to what you can support. If the system is too invertebrate-ish, = it won't provide any support and will just become a morass of useless = tissue.=20 On Apr 22, 2013, at 17:48, Warren Kumari wrote: > Um, I'm probably missing something obvious here, but you cannot use = CDS to enroll in DNSSEC. This means that you'll have to use the original = out-of-band system -- what if we extend Wes's radio buttons to include = ZSK / KSK[0]? Ultimately, I'm still uncomfortable with anything that does not use the = out-of-band mechanism. At the start of this thread was the question of = "what if the secrecy of the KSK private key is lost? How do you go = forward?" Conventional wisdom du jure is that the only "gotta do it" reason for a = key change is just about that case. All the other reasons are more or = less window dressing. (Yes, you could totally lose the private key, but = then there's no way to roll out of it "in band.") I can't see how a reasonable approach can be made to work only in-band. = Ever. Where reasonable means "has no gaping holes that might actually = happen in operations." = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_95DBB78D-4A00-4602-AEA1-8A9C24023DFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
There is nothing = preventing a CDS record from doing both automated
marshaling and = accept *or* just automated = marshaling.

I agree - in the sense = that the "science behind it" allows for one marshaling mechanism to be = used different ways.

What I am leery of is that = once an RFC is published saying "here's how you marshall it" and "here's = how the data transfer works" the perception is that to "do" CDS at all = you have to both use the record and do it that way.  I speak from = the experience of answering RFPs that ask for comments about compliance = with a laundry list of RFCs.  Buyers (RFP issuers) rarely show that = they've read the RFCs by referencing only the applicable sections to the = bid, and commonly an RFP writer will copy another RFP lock, stock and = barrel when it comes to things like technical = details.

So, my "gating requirement" for the = proposal is that the document does it's best to say "here's a good = marshaling data structure" and separably "here's one way to use it" and = preferably "here's another way to use it."

This = gating requirement is strictly a "how it is written" issue.  And, I = do think it is very important that the document is very clear so that = when it comes to RFP or compliance or even audit time, = legal/contractural issues are = minimized.

On Apr 22, 2013, at 16:19, = Wes Hardaker wrote:

So,= if it didn't change the what-must-sign it rule, would you come = to
support = it?

It is not so = simple.  In one of my long-winded, rambling, stream of = consciousness messages I suggested that there be no change to "how it is = signed" and "how it is validated" rules.  Special rules can be = written for the provisioning system - an yes, the signer has to know to = support that.

I firmly believe that a validator = (as described in 4033-4035) should have to be altered for the CDS = proposal.  But I have far less of an objection to having the = element that accepts the CDS from the child having special rules - = mostly because these do not exist today, there's no code to retrofit, no = backwards compatibility concerns.

On Apr = 22, 2013, at 17:41, Doug Barton wrote:

On = 04/22/2013 02:19 PM, Joe Abley wrote:

On 2013-04-22, = at 17:17, Wes Hardaker <wjhns1@hardakers.net> = wrote:

Wes Hardaker <wjhns1@hardakers.net> = writes:

FYI: I meant to mention that = there is a significant number of = operators
that do actually protect their = keys with different levels of = protection
and keep their KSKs in a "better = vault".

That's = interesting. Can you cite examples?

The only = example I know of is the root zone, which is weird and special for a = variety of non-technical reasons. Last time I looked neither the BIND9 = nor OpenDNSSEC toolchains supported offline-KSK operations without a lot = of hackery.

Various TLDs discussed their plans to = take similar steps at various points in the past. There is no reason to = believe that other sites (particularly large financials) wouldn't be = doing the same.

That said, I don't see any reason to introduce = "ZSK can validate a CDS record," and lots of reasons to require the = KSK(s) to do so. If off-line KSK users can't use CDS to do their thing, = I'm sure they would consider that an acceptable = compromise.

Back = in the day, (meaning in the late 90's before the first workshops) we = (Olafur, Brian, Russ and I) toyed with many ways to do DNSSEC.  One = was to have off-line keys like KSKs (well before we made the split in = the workshops) and to have on-line keys like ZSKs and denote them with = "key strength" bits.  The idea was that we'd have a protected key = for data that needed high assurance and a vulnerable key for data that = needed convenience.  We quickly realized that this was non-sense as = "a chain is only as strong as it's weakest link."  In normal = operations it just doesn't make sense to split the key = management.

Now, Joe is right.  The root zone is = a special case.  While "weird" is a flippant word to use here, it = seriously deserves a different treatment - and the root zone gets that = treatment.

What I am saying is, if there are = cases of someone thinking that it is worth the time to split KSK and = ZSK, I'd urge them to reconsider.  It's not terrible but it is over = engineering.  I'm not inclined to "optimize" for such an use case. =  I'm for choice in how to operate.  But there are limits to = what you can support.  If the system is too invertebrate-ish, it = won't provide any support and will just become a morass of useless = tissue. 


On = Apr 22, 2013, at 17:48, Warren Kumari wrote:

Um, = I'm probably missing something obvious here, but you cannot use CDS to = enroll in DNSSEC. This means that you'll have to use the original = out-of-band system -- what if we extend Wes's radio buttons to include = ZSK / KSK[0]?

Ultimately, I'm still = uncomfortable with anything that does not use the out-of-band mechanism. =  At the start of this thread was the question of "what if the = secrecy of the KSK private key is lost? How do you go = forward?"

Conventional wisdom du jure is that = the only "gotta do it" reason for a key change is just about that case. =  All the other reasons are more or less window dressing. =  (Yes, you could totally lose the private key, but then there's no = way to roll out of it "in band.")

 I can't = see how a reasonable approach can be made to work only in-band. =  Ever.  Where reasonable means "has no gaping holes that might = actually happen in operations."


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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_95DBB78D-4A00-4602-AEA1-8A9C24023DFB-- From warren@kumari.net Tue Apr 23 07:44:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C8821F960E for ; Tue, 23 Apr 2013 07:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[AWL=-0.598, 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 bsSV2f9WjA3J for ; Tue, 23 Apr 2013 07:44:39 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B7C21F9609 for ; Tue, 23 Apr 2013 07:44:38 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 327081B40244; Tue, 23 Apr 2013 10:44:38 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: Date: Tue, 23 Apr 2013 10:44:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: Edward Lewis X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 14:44:40 -0000 On Apr 23, 2013, at 10:21 AM, Edward Lewis wrote: > I'm going to attempt to reply to a few messages in one. =85 and I'm going to snip a whole bunch of text and just respond to part = of it :-) [ SNIP ] >=20 > On Apr 22, 2013, at 17:48, Warren Kumari wrote: >=20 >> Um, I'm probably missing something obvious here, but you cannot use = CDS to enroll in DNSSEC. This means that you'll have to use the original = out-of-band system -- what if we extend Wes's radio buttons to include = ZSK / KSK[0]? >=20 > Ultimately, I'm still uncomfortable with anything that does not use = the out-of-band mechanism. =20 Unfortunately the whole point of the CDS draft is to allow rolling of = keys without having to do the whole out-of-band thing.=20 The problem statement is basically: "It is really annoying to have to go = to my registrar (or whatever other parental relationship I have) and = click through a whole bunch of screens to finally get to the place where = I enter the DS. I'm ok to do this once or twice, but having to do it = times every sucks and so I just don't do it at all". (where is the number of domains I hold and is my key roll = interval (and *please* let's not get into any religious arguments about = the value (or even units) of )) > At the start of this thread was the question of "what if the secrecy = of the KSK private key is lost? How do you go forward?" You: 1: Curse. 2: Figure out how it happened. 3: Bitch at Bob, who decided to back it up by printing it out on a pile = of 8.5"x11" and then left it under his keyboard. 4: Suck it up and log onto the registrars web site (or however else you = securely communicate with your parent) and click the "Delete *ALL* DS = records" button, then click the "Add DS record" button and manually = enroll a new DS (just like you currently do=85) 5: Remove Bob's sudo access. 6: Profit! >=20 > Conventional wisdom du jure is that the only "gotta do it" reason for = a key change is just about that case. All the other reasons are more or = less window dressing. (Yes, you could totally lose the private key, but = then there's no way to roll out of it "in band.") This is only "conventional wisdom" amongst some folk -- some folk wish = to be able to roll their keys every X weeks / months / years. This is = for a variety of reasons, from the sane to the crazy, but it (IMO) their = right to decide how often (or even if) they wish to roll. > I can't see how a reasonable approach can be made to work only = in-band. Ever. Where reasonable means "has no gaping holes that might = actually happen in operations. >=20 >=20 > = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > Edward Lewis =20 > NeuStar You can leave a voice message at = +1-571-434-5468 >=20 > There are no answers - just tradeoffs, decisions, and responses. >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 There are only 10 types of people in this world -- those who understand = binary arithmetic and those who don't. From ed.lewis@neustar.biz Tue Apr 23 08:18:45 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DF321F9642 for ; Tue, 23 Apr 2013 08:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 yaRRHJXkSlo5 for ; Tue, 23 Apr 2013 08:18:44 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8F92321F963F for ; Tue, 23 Apr 2013 08:18:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 2A92E18033A; Tue, 23 Apr 2013 11:18:44 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id CEC6C18048D; Tue, 23 Apr 2013 11:18:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_42E42637-8E58-4902-BB8D-F13C4AC3AE2D" From: Edward Lewis In-Reply-To: Date: Tue, 23 Apr 2013 11:18:41 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 15:18:45 -0000 --Apple-Mail=_42E42637-8E58-4902-BB8D-F13C4AC3AE2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 23, 2013, at 10:44, Warren Kumari wrote: >=20 > Unfortunately the whole point of the CDS draft is to allow rolling of = keys without having to do the whole out-of-band thing.=20 What's really unfortunate is that the CDS record could be flexible = enough to work with an out-of-band arrangement if the proposal = well-designed, but if the document insists on weaving in an in-band only = arrangement, the idea will flail. Opportunity to be useful is lost. > The problem statement is basically: "It is really annoying to have to = go to my registrar (or whatever other parental relationship I have) and = click through a whole bunch of screens to finally get to the place where = I enter the DS. I'm ok to do this once or twice, but having to do it = times every sucks and so I just don't do it at all". For zones that operate under a mandate of the ICANN-style shared = registry model, you can't bypass the registrar. If this is something that a registrar will make use of to allow it's = customers to pass DS material to the parent, if there is not significant = support from registrars then this will be a hollow proposal. My = challenge then is to see demonstrated support from the registrars and = sufficient adoption that there's pay off. Or else we wasting our time. I say that because it's been suggested that registrars would rather have = registrants log in more often than less for other marketing reasons. = (But I don't know, I'm just saying I've heard that.) . . . I see great potential in this proposal as the corner stone of a general = approach to the problem. Weighing it down by tying it to one use case = or one set of operational assumptions will not only kill it's payoff the = weight will kill off the ability to use the important bits and pieces in = a more general approach. That is why I bother thinking about CDS at = all. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_42E42637-8E58-4902-BB8D-F13C4AC3AE2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Unfortunately = the whole point of the CDS draft is to allow rolling of keys without = having to do the whole out-of-band thing. =

What's really unfortunate is that = the CDS record could be flexible enough to work with an out-of-band = arrangement if the proposal well-designed, but if the document insists = on weaving in an in-band only arrangement, the idea will flail. =  Opportunity to be useful is lost.

The problem statement is basically: "It is really = annoying to have to go to my registrar (or whatever other parental = relationship I have) and click through a whole bunch of screens to = finally get to the place where I enter the DS. I'm ok to do this once or = twice, but having to do it <blargh> times every <foo> sucks = and so I just don't do it at = all".

For zones that operate under = a mandate of the ICANN-style shared registry model, you can't bypass the = registrar.

If this is something that a = registrar will make use of to allow it's customers to pass DS material = to the parent, if there is not significant support from registrars then = this will be a hollow proposal.  My challenge then is to see = demonstrated support from the registrars and sufficient adoption that = there's pay off.  Or else we wasting our = time.

I say that because it's been = suggested that registrars would rather have registrants log in more = often than less for other marketing reasons.  (But I don't know, = I'm just saying I've heard that.)

. . = .

I see great potential in this proposal as the = corner stone of a general approach to the problem.  Weighing it = down by tying it to one use case or one set of operational assumptions = will not only kill it's payoff the weight will kill off the ability to = use the important bits and pieces in a more general approach.  That = is why I bother thinking about CDS at all.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_42E42637-8E58-4902-BB8D-F13C4AC3AE2D-- From warren@kumari.net Tue Apr 23 08:35:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EE321F9684 for ; Tue, 23 Apr 2013 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.651 X-Spam-Level: X-Spam-Status: No, score=-101.651 tagged_above=-999 required=5 tests=[AWL=-0.449, 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 E+OO0qKxD9Uc for ; Tue, 23 Apr 2013 08:35:46 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF64221F9682 for ; Tue, 23 Apr 2013 08:35:45 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id C24291B40599; Tue, 23 Apr 2013 11:35:44 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: Date: Tue, 23 Apr 2013 11:35:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <44E61500-9A8C-46DA-835A-FB36D4909D84@kumari.net> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: Edward Lewis X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 15:35:47 -0000 On Apr 23, 2013, at 11:18 AM, Edward Lewis wrote: >=20 > On Apr 23, 2013, at 10:44, Warren Kumari wrote: >>=20 >> Unfortunately the whole point of the CDS draft is to allow rolling of = keys without having to do the whole out-of-band thing.=20 >=20 > What's really unfortunate is that the CDS record could be flexible = enough to work with an out-of-band arrangement if the proposal = well-designed, but if the document insists on weaving in an in-band only = arrangement, the idea will flail. Opportunity to be useful is lost. >=20 >> The problem statement is basically: "It is really annoying to have to = go to my registrar (or whatever other parental relationship I have) and = click through a whole bunch of screens to finally get to the place where = I enter the DS. I'm ok to do this once or twice, but having to do it = times every sucks and so I just don't do it at all". >=20 > For zones that operate under a mandate of the ICANN-style shared = registry model, you can't bypass the registrar. >=20 > If this is something that a registrar will make use of to allow it's = customers to pass DS material to the parent, if there is not significant = support from registrars then this will be a hollow proposal. If you build it they may come. If you don't build it you'll never know=85 = A number of registrars have mumbled that it seems like a reasonable = idea. There are also registrars that cater to larger customers (with = thousands of domains), they would rather keep the account instead of = displaying ads. This is apse designed for places where you don't have a = traditional registrar (think organizations / educational institutes, = etc) > My challenge then is to see demonstrated support from the registrars = and sufficient adoption that there's pay off. Or else we wasting our = time. >=20 > I say that because it's been suggested that registrars would rather = have registrants log in more often than less for other marketing = reasons. (But I don't know, I'm just saying I've heard that.) >=20 > . . . >=20 > I see great potential in this proposal as the corner stone of a = general approach to the problem. Weighing it down by tying it to one = use case or one set of operational assumptions will not only kill it's = payoff the weight will kill off the ability to use the important bits = and pieces in a more general approach. =20 See Wes's suggestion on radio buttons. If you are a registrar[0] who wants to specify that your users have to = login and click a "I've published a CDS record, please import that" = button no-one[1] can stop you=85 W [0]: as an example [1]: I'm assuming no-one can stop you, but who knows... > That is why I bother thinking about CDS at all. >=20 > = -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > Edward Lewis =20 > NeuStar You can leave a voice message at = +1-571-434-5468 >=20 > There are no answers - just tradeoffs, decisions, and responses. >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they = can talk but choose not to do so in case humans put them to work, = possibly in the television industry. In fact they can talk. It's just = that they talk in Orang-utan. Humans are only capable of listening in = Bewilderment. -- Terry Practhett From paul.hoffman@vpnc.org Tue Apr 23 08:52:14 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616E321F95D0 for ; Tue, 23 Apr 2013 08:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 3ZE+RYs4Hzc0 for ; Tue, 23 Apr 2013 08:52:13 -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 ADD7A21F95E5 for ; Tue, 23 Apr 2013 08:52:10 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3NFq85O017614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Apr 2013 08:52:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Tue, 23 Apr 2013 08:52:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71598986-48E0-4175-8FC0-8EE0EC800777@vpnc.org> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: Edward Lewis X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 15:52:14 -0000 On Apr 23, 2013, at 8:18 AM, Edward Lewis wrote: > What's really unfortunate is that the CDS record could be flexible = enough to work with an out-of-band arrangement if the proposal = well-designed, but if the document insists on weaving in an in-band only = arrangement, the idea will flail. Opportunity to be useful is lost. You are conflating two features that you want: in-band signaling and = out-of-DNS-band authorization. It is perfectly reasonable for a parent to have a policy of "we will not = look for a CDS until we have gotten an authenticated request to do so", = and that request mechanism can be a standardized HTTP request. Designing = the latter is trivial and can be done in parallel with the CDS work. FWIW, I think that the out-of-band "make me look" protocol is quite = worthwhile. The more I look at some of the weirdness that is in CDS = (artificial differences of KSK and ZSK, partial signing, etc.), the more = I think that trying to do this in DNS under DNSSEC is stretching the DNS = too far.=20 On Apr 18, 2013, at 5:11 PM, Joe Abley wrote: > By this thinking, a signed apex DS RRSet with the meaning discussed = for CDS could be deployed today, with no need for code point assignment. = What am I missing? ... was followed by throwing out the idea because: On Apr 19, 2013, at 7:14 AM, Tony Finch wrote: > That isn't enough to disambiguate which DS is being asked for if child = and > parent zones share a server. With a secure out-of-DNS-band authorization that says "please fetch my = DS records, and they will look like X" where X is the record or a hash = of the record, there is no problem with signed apex DS RRsets even when = the child and parent zones share a server. --Paul Hoffman= From paul@cypherpunks.ca Tue Apr 23 08:58:57 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7847421F95F7 for ; Tue, 23 Apr 2013 08:58:57 -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 JGyGApLx1coK for ; Tue, 23 Apr 2013 08:58:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0040D21F95F0 for ; Tue, 23 Apr 2013 08:58:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zw8Tl4RnLz9h2; Tue, 23 Apr 2013 11:58:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id n5oo-X-7qOaU; Tue, 23 Apr 2013 11:58:50 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 23 Apr 2013 11:58:50 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0DF6880EC7; Tue, 23 Apr 2013 11:58:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EEBEA80E19; Tue, 23 Apr 2013 11:58:48 -0400 (EDT) Date: Tue, 23 Apr 2013 11:58:48 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Edward Lewis In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 15:58:57 -0000 On Tue, 23 Apr 2013, Edward Lewis wrote: > What I am saying is, if there are cases of someone thinking that it is worth the time to split KSK > and ZSK, I'd urge them to reconsider. If your nameserver requires the private ZSK for inline/ondemand signing, like bind or powerdns, then having the KSK offline on another machine is a very valid use case. The CDS record should not break that. Paul From paul@cypherpunks.ca Tue Apr 23 09:07:38 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C055E21F9399 for ; Tue, 23 Apr 2013 09:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=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 eMhCG3e5N4cW for ; Tue, 23 Apr 2013 09:07:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id EAAD521F93FC for ; Tue, 23 Apr 2013 09:07:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zw8gq16lVz9h2; Tue, 23 Apr 2013 12:07:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yHsMiBmZ1wnC; Tue, 23 Apr 2013 12:07:34 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 23 Apr 2013 12:07:34 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id DE5F380EC7; Tue, 23 Apr 2013 12:07:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CFA2880E19; Tue, 23 Apr 2013 12:07:34 -0400 (EDT) Date: Tue, 23 Apr 2013 12:07:34 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Edward Lewis In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:07:38 -0000 On Tue, 23 Apr 2013, Edward Lewis wrote: > For zones that operate under a mandate of the ICANN-style shared registry model, you can't bypass > the registrar. Thing could change. > If this is something that a registrar will make use of to allow it's customers to pass DS material > to the parent, if there is not significant support from registrars then this will be a hollow > proposal. There are many very sane CC:TLDs out there too. > I say that because it's been suggested that registrars would rather have registrants log in more > often than less for other marketing reasons.  (But I don't know, I'm just saying I've heard that.) I believe in the free market. I recommend gkg.net as a registrar because they do allow me to send JSON requests to them for DS updates of my domains. So let's not use marketing arguments for protocol design. Paul From ed.lewis@neustar.biz Tue Apr 23 09:11:39 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DF121F965D for ; Tue, 23 Apr 2013 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.035 X-Spam-Level: X-Spam-Status: No, score=-102.035 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 78H-B0d6o9Od for ; Tue, 23 Apr 2013 09:11:38 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5D621F8654 for ; Tue, 23 Apr 2013 09:11:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 445E93A04B4; Tue, 23 Apr 2013 12:11:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 064203A04DF; Tue, 23 Apr 2013 12:11:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D5F2A1A-A4F0-42D4-A65A-897F26B39953" From: Edward Lewis In-Reply-To: <71598986-48E0-4175-8FC0-8EE0EC800777@vpnc.org> Date: Tue, 23 Apr 2013 12:11:31 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <71598986-48E0-4175-8FC0-8EE0EC800777@vpnc.org> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:11:39 -0000 --Apple-Mail=_0D5F2A1A-A4F0-42D4-A65A-897F26B39953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 23, 2013, at 11:52, Paul Hoffman wrote: >=20 > It is perfectly reasonable for a parent to have a policy of "we will = not look for a CDS until we have gotten an authenticated request to do = so", and that request mechanism can be a standardized HTTP request. = Designing the latter is trivial and can be done in parallel with the CDS = work. >=20 > FWIW, I think that the out-of-band "make me look" protocol is quite = worthwhile. The more I look at some of the weirdness that is in CDS = (artificial differences of KSK and ZSK, partial signing, etc.), the more = I think that trying to do this in DNS under DNSSEC is stretching the DNS = too far.=20 >=20 I agree with both of those statements. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_0D5F2A1A-A4F0-42D4-A65A-897F26B39953 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

It is = perfectly reasonable for a parent to have a policy of "we will not look = for a CDS until we have gotten an authenticated request to do so", and = that request mechanism can be a standardized HTTP request. Designing the = latter is trivial and can be done in parallel with the CDS = work.

FWIW, I think that the out-of-band "make me look" protocol = is quite worthwhile. The more I look at some of the weirdness that is in = CDS (artificial differences of KSK and ZSK, partial signing, etc.), the = more I think that trying to do this in DNS under DNSSEC is stretching = the DNS too far.


I agree = with both of those statements.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_0D5F2A1A-A4F0-42D4-A65A-897F26B39953-- From ed.lewis@neustar.biz Tue Apr 23 09:15:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508E521F9389 for ; Tue, 23 Apr 2013 09:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 JqfbG6l3td0O for ; Tue, 23 Apr 2013 09:15:42 -0700 (PDT) Received: from smtp149.ord.emailsrvr.com (smtp149.ord.emailsrvr.com [173.203.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 8920221F9356 for ; Tue, 23 Apr 2013 09:15:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 1545B2701CE; Tue, 23 Apr 2013 12:15:42 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp15.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 97CAA270124; Tue, 23 Apr 2013 12:15:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_345F80A9-ACE4-4D6B-B800-151E3F42F030" From: Edward Lewis In-Reply-To: Date: Tue, 23 Apr 2013 12:15:40 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: [DNSOP] Key management tricks was Re: Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:15:43 -0000 --Apple-Mail=_345F80A9-ACE4-4D6B-B800-151E3F42F030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 23, 2013, at 11:58, Paul Wouters wrote: > On Tue, 23 Apr 2013, Edward Lewis wrote: >=20 > If your nameserver requires the private ZSK for inline/ondemand = signing, > like bind or powerdns, then having the KSK offline on another machine = is > a very valid use case. The CDS record should not break that. I don't agree with that - if the ZSK is compromised, what good is having = a non-compromized KSK? For anyone other than the root, changing the KSK = is pretty trivial. Even without CDS. Back in the day, one of the fears was weak host security. That's gotten = a lot better. And the use of hidden masters inside protected enclaves = has become much more common. With these advancements over time, = complicating key management is less desirable. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_345F80A9-ACE4-4D6B-B800-151E3F42F030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Tue, 23 Apr 2013, Edward Lewis wrote:

If your nameserver requires = the private ZSK for inline/ondemand signing,
like bind or powerdns, = then having the KSK offline on another machine is
a very valid use = case. The CDS record should not break = that.

I don't agree with that = - if the ZSK is compromised, what good is having a non-compromized KSK? =  For anyone other than the root, changing the KSK is pretty = trivial.  Even without CDS.

Back in the day, one = of the fears was weak host security.  That's gotten a lot better. =  And the use of hidden masters inside protected enclaves has become = much more common.   With these advancements over time, complicating = key management is less desirable.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_345F80A9-ACE4-4D6B-B800-151E3F42F030-- From ed.lewis@neustar.biz Tue Apr 23 09:26:57 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C6021F9530 for ; Tue, 23 Apr 2013 09:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.711 X-Spam-Level: X-Spam-Status: No, score=-101.711 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_24=0.6, MIME_QP_LONG_LINE=1.396, 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 TXQZqIaY0RRJ for ; Tue, 23 Apr 2013 09:26:56 -0700 (PDT) Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com [67.192.241.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2B821F9552 for ; Tue, 23 Apr 2013 09:26:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 4644E3A03B3; Tue, 23 Apr 2013 12:26:56 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id 01FFC3A01DD; Tue, 23 Apr 2013 12:26:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8E2560C0-374C-48C2-BC1E-720FF98C0046" From: Edward Lewis In-Reply-To: Date: Tue, 23 Apr 2013 12:26:55 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:26:57 -0000 --Apple-Mail=_8E2560C0-374C-48C2-BC1E-720FF98C0046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 23, 2013, at 12:07, Paul Wouters wrote: > There are many very sane CC:TLDs out there too. The point is that there are arrangements where you can't talk directly. = And there are arrangements were you can talk directly. And there are = arrangements where the lingua franca is DNSKEY and not DS. There are = many environments. That is why I'm fighting a one-size fits all, = in-band only solution. > I believe in the free market. I recommend gkg.net as a registrar = because > they do allow me to send JSON requests to them for DS updates of my > domains. So let's not use marketing arguments for protocol design. I have a hard time not saying this sarcastically - yeah, let's ignore = reality. "Marketing" and "market forces" determine our requirements. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_8E2560C0-374C-48C2-BC1E-720FF98C0046 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
There = are many very sane CC:TLDs out there = too.

The point is that there = are arrangements where you can't talk directly.  And there are = arrangements were you can talk directly.  And there are = arrangements where the lingua franca is DNSKEY and not DS.  There = are many environments.  That is why I'm fighting a one-size fits = all, in-band only solution.

I believe in the free market. I recommend gkg.net as a registrar because
they do = allow me to send JSON requests to them for DS updates of my
domains. = So let's not use marketing arguments for protocol = design.

I have a = hard time not saying this sarcastically - yeah, let's ignore = reality.

"Marketing" and "market forces" = determine our requirements.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_8E2560C0-374C-48C2-BC1E-720FF98C0046-- From paul@cypherpunks.ca Tue Apr 23 09:39:21 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4441F21F8B2B for ; Tue, 23 Apr 2013 09:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 vcDlnpvQPYdm for ; Tue, 23 Apr 2013 09:39:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A73EE21F8ADC for ; Tue, 23 Apr 2013 09:39:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zw9NQ3fDMz9h9; Tue, 23 Apr 2013 12:39:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id rq7no_8qzCao; Tue, 23 Apr 2013 12:39:18 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 23 Apr 2013 12:39:17 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id A245A80EC7; Tue, 23 Apr 2013 12:39:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9714B805CC; Tue, 23 Apr 2013 12:39:18 -0400 (EDT) Date: Tue, 23 Apr 2013 12:39:18 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Edward Lewis In-Reply-To: Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:39:21 -0000 On Tue, 23 Apr 2013, Edward Lewis wrote: > The point is that there are arrangements where you can't talk directly.  And there are > arrangements were you can talk directly.  And there are arrangements where the lingua franca is > DNSKEY and not DS.  There are many environments.  That is why I'm fighting a one-size fits all, > in-band only solution. People suggesting CDS are not suggesting implementing this is mandatory, and is the One True Way. In fact, it is quite the reverse. CDS proponents want to _ability_ to signal inband using the DNS and existing trust anchors (DS-KSK pairing), and no desire to abolish existing out of band methods. Everyone who does not like any of this in-band DNS stuff is free to ignore CDS records at children, and not publish them for parents. Whether dictated by (in)sanity, lawyers, or the White Knights scaling the ICANN Ivory Towers or Ayn Rand. I get it, you don't like the concept. So don't use it. For those who _do_ like the concept, let's get to a specification that can be useful to most without crippling the basic use case of "using an existing authenticated trust relationship in-band to the DNS for automated updates of the DS record" (and/or NS/GLUE records) Paul From paul.hoffman@vpnc.org Tue Apr 23 10:16:26 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83C621F9195 for ; Tue, 23 Apr 2013 10:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 xoVBi9GZfOjt for ; Tue, 23 Apr 2013 10:16:26 -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 234C521F93C7 for ; Tue, 23 Apr 2013 10:16:19 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3NHG7xQ021001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Apr 2013 10:16:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Tue, 23 Apr 2013 10:16:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: Paul Wouters X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:16:27 -0000 On Apr 23, 2013, at 9:39 AM, Paul Wouters wrote: > I get it, you don't like the concept. So don't use it. For those who = _do_ > like the concept, let's get to a specification that can be useful to = most > without crippling the basic use case of "using an existing = authenticated > trust relationship in-band to the DNS for automated updates of the DS > record" (and/or NS/GLUE records) Except that this thread has brought out many problems in the -01 draft = that will likely result in changes that will make CDS special, not just = like other records. At that point, you will have to decide if having a = CDS record is a better idea than just re-using DS. --Paul Hoffman= From ed.lewis@neustar.biz Tue Apr 23 11:37:33 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123BB21F9749 for ; Tue, 23 Apr 2013 11:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.956 X-Spam-Level: X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 yGRJsXj2WwLV for ; Tue, 23 Apr 2013 11:37:32 -0700 (PDT) Received: from smtp205.dfw.emailsrvr.com (smtp205.dfw.emailsrvr.com [67.192.241.205]) by ietfa.amsl.com (Postfix) with ESMTP id D330721F9748 for ; Tue, 23 Apr 2013 11:37:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6D5791B80E5; Tue, 23 Apr 2013 14:37:31 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp10.relay.dfw1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id B21041B803D; Tue, 23 Apr 2013 14:37:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F74EFE7-4021-489E-B4EC-BE7165230D66" From: Edward Lewis In-Reply-To: Date: Tue, 23 Apr 2013 14:37:29 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:37:33 -0000 --Apple-Mail=_2F74EFE7-4021-489E-B4EC-BE7165230D66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 23, 2013, at 12:39, Paul Wouters wrote: > I get it, you don't like the concept. No, that's not true. I see great utility in placing whatever is needed to describe the = desired DS set state into a record to avoid having to transfer the data = in any other format. I fear that specifying a single in-band signaling mechanism could wind = up tying a potentially valuable means of ferrying data to a particular = use case, preventing a more general solution from moving into use. If I didn't like concept, I wouldn't have been thinking about it and how = close it is to begin useful. What I feel I am reading in this thread is that some folks are already = wedded to the current document and are unwilling to alter it for greater = applicability. Alarming to me is the thought that changing the basic validation = algorithm to require a particular data set be signed with a particular = key (role) would be something "simple." = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_2F74EFE7-4021-489E-B4EC-BE7165230D66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I get = it, you don't like the concept.

No, = that's not true.

I see great utility in placing = whatever is needed to describe the desired DS set state into a record to = avoid having to transfer the data in any other = format.

I fear that specifying a single in-band = signaling mechanism could wind up tying a potentially valuable means of = ferrying data to a particular use case, preventing a more general = solution from moving into use.

If I didn't like = concept, I wouldn't have been thinking about it and how close it is to = begin useful.

What I feel I am reading in this = thread is that some folks are already wedded to the current document and = are unwilling to alter it for greater = applicability.

Alarming to me is the thought = that changing the basic validation algorithm to require a particular = data set be signed with a particular key (role) would be something = "simple."

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_2F74EFE7-4021-489E-B4EC-BE7165230D66-- From ogud@ogud.com Tue Apr 23 12:33:45 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0A821F9766 for ; Tue, 23 Apr 2013 12:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 8w4sURULylFG for ; Tue, 23 Apr 2013 12:33:44 -0700 (PDT) Received: from smtp109.ord1c.emailsrvr.com (smtp109.ord1c.emailsrvr.com [108.166.43.109]) by ietfa.amsl.com (Postfix) with ESMTP id 7445421F9759 for ; Tue, 23 Apr 2013 12:33:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C79E598121; Tue, 23 Apr 2013 15:33:43 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5BBDD980E2; Tue, 23 Apr 2013 15:33:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olafur Gudmundsson In-Reply-To: <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> Date: Tue, 23 Apr 2013 15:33:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E348F71-7B38-4027-B406-1FFAD4FF7A48@ogud.com> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: IETF DNSOP WG , Paul Wouters Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 19:33:45 -0000 On Apr 23, 2013, at 1:16 PM, Paul Hoffman wrote: > On Apr 23, 2013, at 9:39 AM, Paul Wouters wrote: >=20 >> I get it, you don't like the concept. So don't use it. For those who = _do_ >> like the concept, let's get to a specification that can be useful to = most >> without crippling the basic use case of "using an existing = authenticated >> trust relationship in-band to the DNS for automated updates of the DS >> record" (and/or NS/GLUE records) >=20 > Except that this thread has brought out many problems in the -01 draft = that will likely result in changes that will make CDS special, not just = like other records. At that point, you will have to decide if having a = CDS record is a better idea than just re-using DS. The first rule of protocol extensions is "avoid harm" to existing = systems.=20 Reusing DS at child side of delegation is likely to cause harm.=20 In order to signal TA changes in-band thus has to be done either using = new RRtype or only DNSKEY records.=20 =46rom a regular validator perspective CDS is a normal record, that is = signed by a key that is in the DNSKEY RRset thus=20 it validates like any any other record.=20 A system that consume CDS records as a matter of Trust Anchor = Maintenance require special rules before using the records content=20 to update trust anchors these rules are likely to apply to any other = mechanism used in-band.=20 Mandatory Rules are:=20 - signed by one of current trust anchor(s) - applying new trust anchor(s) will not break chain of trust=20 - absence of CDS implies NO change in Trust Anchor=20 Optional Rules:=20 - accept after delay similar to RFC5011=20 - accept only if DNSKEY contains all keys referred to in the CDS=20= - accept only if DS algorithms are "acceptable" - accept if there is a by "child"=20 If you agree with the mandatory rules and a subset of the optional rules = then you agree with the basic premise of the next version of the draft that will be much clearer on what is Required and what is = Optional. Olafur From dougb@dougbarton.us Tue Apr 23 13:40:59 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5C21F94A4 for ; Tue, 23 Apr 2013 13:40:59 -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 HP6oRdKroeEU for ; Tue, 23 Apr 2013 13:40:58 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6643421F95EB for ; Tue, 23 Apr 2013 13:40:58 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47] (unknown [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47]) by dougbarton.us (Postfix) with ESMTPSA id 05B2622B78 for ; Tue, 23 Apr 2013 20:40:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366749658; bh=zzG8UFjXDrWvTYtv9RChq89DpAooBUEOO74cNPdBHhQ=; h=Date:From:To:Subject:References:In-Reply-To; b=fxj+56L+bIiNnZ7RrRb0FqkTqyCNbo0WJ9YWPnIWGrQ+zxbkEEraoAMUzHep2Ocv0 NyL1lrR+1yyy49F87Utib9YGLhHOioFzDY4KCniNZ5nlh/zrDYCiVocHD3aqHShRjq EfYG51YNN6wfMxU0SJtZ5qxBnQ5wRyEnZQfiDsoU= Message-ID: <5176F1D9.20300@dougbarton.us> Date: Tue, 23 Apr 2013 13:40:57 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsop@ietf.org References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 20:40:59 -0000 FWIW, I agree with Ed's points below (some of which I have expressed previously). Doug On 04/23/2013 11:37 AM, Edward Lewis wrote: > > On Apr 23, 2013, at 12:39, Paul Wouters wrote: > >> I get it, you don't like the concept. > > No, that's not true. > > I see great utility in placing whatever is needed to describe the > desired DS set state into a record to avoid having to transfer the data > in any other format. > > I fear that specifying a single in-band signaling mechanism could wind > up tying a potentially valuable means of ferrying data to a particular > use case, preventing a more general solution from moving into use. > > If I didn't like concept, I wouldn't have been thinking about it and how > close it is to begin useful. > > What I feel I am reading in this thread is that some folks are already > wedded to the current document and are unwilling to alter it for greater > applicability. > > Alarming to me is the thought that changing the basic validation > algorithm to require a particular data set be signed with a particular > key (role) would be something "simple." > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > There are no answers - just tradeoffs, decisions, and responses. > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From wjhns1@hardakers.net Tue Apr 23 13:51:04 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96B21F93F6 for ; Tue, 23 Apr 2013 13:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 MyQiMJiHGTaS for ; Tue, 23 Apr 2013 13:51:03 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id E9AE421F93F0 for ; Tue, 23 Apr 2013 13:50:59 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id 4039B27A15; Tue, 23 Apr 2013 13:50:53 -0700 (PDT) From: Wes Hardaker To: Warren Kumari References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <5DB01471-CBFF-441F-AD74-C6A101234679@neustar.biz> <0l4neyfhdw.fsf@wjh.hardakers.net> <0lobd61d0e.fsf@wjh.hardakers.net> <5175AE8F.1090803@dougbarton.us> Date: Tue, 23 Apr 2013 13:50:52 -0700 In-Reply-To: (Warren Kumari's message of "Mon, 22 Apr 2013 17:48:25 -0400") Message-ID: <0lmwspeztf.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop@ietf.org Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 20:51:04 -0000 Warren Kumari writes: > Require that this is signed with the KSK? > [] Yes, I have separate process for my keys. > [] Nope, they all live on the same filesystem. If someone gets one, they have the other. That's a very good addition; thank you. -- Wes Hardaker Parsons From wjhns1@hardakers.net Tue Apr 23 13:53:25 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785CA21F9555 for ; Tue, 23 Apr 2013 13:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 8osVcTCgXB1r for ; Tue, 23 Apr 2013 13:53:25 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id F106721F9424 for ; Tue, 23 Apr 2013 13:53:24 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id 0F48F27AE0; Tue, 23 Apr 2013 13:53:23 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> Date: Tue, 23 Apr 2013 13:53:21 -0700 In-Reply-To: (Edward Lewis's message of "Tue, 23 Apr 2013 10:21:36 -0400") Message-ID: <0lip3dezpa.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 20:53:25 -0000 Edward Lewis writes: > I firmly believe that a validator (as described in 4033-4035) should > have to be altered for the CDS proposal. I don't think so at all. Validators will still provide you with a "valid" answer for the CDS record no matter which key is used to sign the RRSIG for it. That's all well and good already. It's the (non-existent) application that will need the special rules. It will have to do additional checks beyond ensure the record is simply "valid". It'll have to check which key was used to sign it. And to say that we don't have that elsewhere and this is new isn't correct either. 5011 has a number of similar semantics. Consider the revoke bit for the simplest and closest to this case. -- Wes Hardaker Parsons From dougb@dougbarton.us Tue Apr 23 13:59:17 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF0421F960C for ; Tue, 23 Apr 2013 13:59:17 -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 U0PeMlW+vMU6 for ; Tue, 23 Apr 2013 13:59:16 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB9921F940E for ; Tue, 23 Apr 2013 13:59:16 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47] (unknown [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47]) by dougbarton.us (Postfix) with ESMTPSA id 4E46822B78 for ; Tue, 23 Apr 2013 20:59:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366750756; bh=F2sZhrdwD1JtyeXHbbwpVnpffMKbLHY3aQjJVkmOBYM=; h=Date:From:To:Subject:References:In-Reply-To; b=DFZK+Dmss3QAp2NcIk6sb8YauUEsCf/C7dTl2WLjT6seLeD4tAJOpRB9m46Bs2qbd KUvqICyg2iofVIJ/Iqc9FE7uWNsR/9uDUlyQCdjCZUHcJu7Y5A8jE0Tp7DN40A4CYE tlzBlU0AwPvlWUM+BiehsxYEA6DoSREDQwkvuL5o= Message-ID: <5176F624.7070309@dougbarton.us> Date: Tue, 23 Apr 2013 13:59:16 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsop@ietf.org References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0lip3dezpa.fsf@wjh.hardakers.net> In-Reply-To: <0lip3dezpa.fsf@wjh.hardakers.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 20:59:17 -0000 On 04/23/2013 01:53 PM, Wes Hardaker wrote: > Edward Lewis writes: > >> I firmly believe that a validator (as described in 4033-4035) should >> have to be altered for the CDS proposal. > > I don't think so at all. Validators will still provide you with a > "valid" answer for the CDS record no matter which key is used to sign > the RRSIG for it. That's all well and good already. > > It's the (non-existent) application that will need the special rules. > It will have to do additional checks beyond ensure the record is simply > "valid". It'll have to check which key was used to sign it. ... thus creating a support problem when the customer checks their CDS record, sees that it is "valid," and then doesn't understand why the parent won't accept it. IMO both signers AND validators would have to be (should be) updated after this draft. Signers should not sign a CDS record with a non-SEP key, validators shouldn't accept those signatures if they are sent. > And to say that we don't have that elsewhere and this is new isn't > correct either. 5011 has a number of similar semantics. Consider the > revoke bit for the simplest and closest to this case. Perhaps you could elaborate? It's not clear to me how that case applies in the child -> parent signalling direction. Doug From wjhns1@hardakers.net Tue Apr 23 14:02:40 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F09F21F940E for ; Tue, 23 Apr 2013 14:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 qkkEBuT2o+i5 for ; Tue, 23 Apr 2013 14:02:39 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFEE21F96E6 for ; Tue, 23 Apr 2013 14:02:39 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id 7161C27AE0; Tue, 23 Apr 2013 14:02:38 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> Date: Tue, 23 Apr 2013 14:02:36 -0700 In-Reply-To: (Edward Lewis's message of "Tue, 23 Apr 2013 10:21:36 -0400") Message-ID: <0la9opez9v.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:02:40 -0000 Edward Lewis writes: > Ultimately, I'm still uncomfortable with anything that does not use > the out-of-band mechanism. At the start of this thread was the > question of "what if the secrecy of the KSK private key is lost? How > do you go forward?" So, you have the following radio buttons in front of you now: - [ ] Write up your solution to the problem (aka, "show me the draft"). I'd really like to see it (truly! I love options! See! Radio buttons!) - Realize that CDS is likely to go forward because a lot of people like it and: - [ ] choose to ignore it because it doesn't fit your desires - [ ] offer concrete suggestions to change it so it does fit your needs (without removing the features that everyone else keeps saying they want (in-band acceptance)) - Try and stop CDS from going forward by: - [ ] Objecting up to WG last call - [ ] Objecting up till IETF last call - [ ] Objecting and then filling an IESG appeal before publication - [ ] Objecting and then pushing the appeal as far you can make it go and stomp your feet really loudly on the ietf@ mailing list. So, unless you're in the last two camps, I probably don't have much more to say on the subject because persuading you likely won't happen if you're anywhere near the last 4. Objecting to the notion without offering fixes is like saying "I don't want soup to exist because watching people eat it might make me want it in the future". I very much understand that you don't want to use the technology. The solution there is still simple: offer a fix (or replacement suggestion) to make it what you want, or don't use it! Which box are you picking? [please don't be the last one; please don't be the last one] -- Wes Hardaker Parsons From wjhns1@hardakers.net Tue Apr 23 14:12:10 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9921F899E for ; Tue, 23 Apr 2013 14:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=-0.357, 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 5ngLm0p1xqZ9 for ; Tue, 23 Apr 2013 14:12:10 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE05B21F8976 for ; Tue, 23 Apr 2013 14:12:09 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id D34E8256F5; Tue, 23 Apr 2013 14:12:08 -0700 (PDT) From: Wes Hardaker To: Edward Lewis References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> Date: Tue, 23 Apr 2013 14:12:07 -0700 In-Reply-To: (Edward Lewis's message of "Tue, 23 Apr 2013 14:37:29 -0400") Message-ID: <0lwqrtc5p4.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DNSOP WG Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:12:10 -0000 Edward Lewis writes: > What I feel I am reading in this thread is that some folks are already > wedded to the current document and are unwilling to alter it for > greater applicability. No one has given alternative suggestions yet, so I fail to see how you're assuming that everyone is wedded to the current one. There is only one proposed solution at this point. [now... the number of times something has been published in the past that I'd have preferred to have the idea in my head published instead but failed to get it out into a draft in time can be counted, hopefully, on the legs of a centipede] -- Wes Hardaker Parsons From wjhns1@hardakers.net Tue Apr 23 14:20:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92A121F90A1 for ; Tue, 23 Apr 2013 14:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, 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 lx10OhhA0lqb for ; Tue, 23 Apr 2013 14:20:45 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 19AC021F9050 for ; Tue, 23 Apr 2013 14:20:45 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id 44019256F5; Tue, 23 Apr 2013 14:20:44 -0700 (PDT) From: Wes Hardaker To: Doug Barton Message-ID: <0lr4i1c5dn.fsf@wjh.hardakers.net> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0lip3dezpa.fsf@wjh.hardakers.net> <5176F624.7070309@dougbarton.us> Date: Tue, 23 Apr 2013 14:20:40 -0700 In-Reply-To: <5176F624.7070309@dougbarton.us> (Doug Barton's message of "Tue, 23 Apr 2013 13:59:16 -0700") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop@ietf.org Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:20:46 -0000 Doug Barton writes: > ... thus creating a support problem when the customer checks their CDS > record, sees that it is "valid," and then doesn't understand why the > parent won't accept it. Yes, but a CDS management tool wouldn't. It's a specific use case. The above is like saying "my MX record validates with DNSSEC so it must be valid", even though the label doesn't point to a real name. It is not the job of a validator to judge how the data itself will be used and guess at any additional constraints that may be placed on it. A CDS record, just like an MX record, can be valid but not usable. [and don't get me started on CNAME breakage in the wild] >> And to say that we don't have that elsewhere and this is new isn't >> correct either. 5011 has a number of similar semantics. Consider the >> revoke bit for the simplest and closest to this case. > > Perhaps you could elaborate? It's not clear to me how that case > applies in the child -> parent signalling direction. A revoke bit is only considered "actionable" (IE, revoke it from your trust storage) if it was signed by the same key that produced the key with the revoke bit turned on. IE, you can have a "valid" key with the revoke bit set, but you shouldn't actually act on it because it wasn't signed by the key itself. See RFC5011, section 2.1, last sentence for the quick summary. The key would still be considered valid by a validator but you shouldn't act on the knowledge of the data in the key. -- Wes Hardaker Parsons From dougb@dougbarton.us Tue Apr 23 15:17:19 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E5021F93B1 for ; Tue, 23 Apr 2013 15:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 OsQd6hwvkiD0 for ; Tue, 23 Apr 2013 15:17:19 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBAD21F93AA for ; Tue, 23 Apr 2013 15:17:19 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47] (unknown [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47]) by dougbarton.us (Postfix) with ESMTPSA id D536B22BA3 for ; Tue, 23 Apr 2013 22:17:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366755438; bh=t+X99Fpf2tTa4b0n4wJsEDBLzoIb+egijb9agUSVtk4=; h=Date:From:To:Subject:References:In-Reply-To; b=wg4TjTrFeHM7p9c4fkOsHZSrau1PX2RVGiwCKc6TezLdyieMk7WWJ86P6WxynupGb mdQ0gMFyxXxwPLZz068uK3YaHivS0B4PioOUAwuB9JP3czUdBVhv3sd8jXLh9MVnc7 RgDYkkWSHm3CLfymPRkmfbzaLGQUooqrAQVSrWbE= Message-ID: <5177086E.2060301@dougbarton.us> Date: Tue, 23 Apr 2013 15:17:18 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsop@ietf.org References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0lip3dezpa.fsf@wjh.hardakers.net> <5176F624.7070309@dougbarton.us> <0lr4i1c5dn.fsf@wjh.hardakers.net> In-Reply-To: <0lr4i1c5dn.fsf@wjh.hardakers.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 22:17:20 -0000 On 04/23/2013 02:20 PM, Wes Hardaker wrote: > Doug Barton writes: > >> ... thus creating a support problem when the customer checks their CDS >> record, sees that it is "valid," and then doesn't understand why the >> parent won't accept it. > > Yes, but a CDS management tool wouldn't. Yeah, I get that. What I'm saying is, that's the problem. > It's a specific use case. The > above is like saying "my MX record validates with DNSSEC so it must be > valid", even though the label doesn't point to a real name. No, the cases you describe bear only a surface similarity (they both have RRSIGs). Whereas given that CDS is a record specifically designed to signal something to the parent _about DNSSEC_, the fact that (from the customer's perspective) the DNSSEC is valid would cause confusion as to why the parent won't accept it. I realize that you and I understand the fine distinction you are attempting to make, my point is that customers won't. > It is not > the job of a validator to judge how the data itself will be used and > guess at any additional constraints that may be placed on it. A CDS > record, just like an MX record, can be valid but not usable. I would argue that as a matter of protocol clarity it shouldn't be possible for a signer to create a RRSIG that the intended consumer of that signature will discard as ... inappropriate(?) in spite of the fact that it validates just fine. But from the standpoint of having been in the registrar business in the past, I would not want to have to explain this problem to a customer (not to mention the revenue-destroying nature of any customer support call in the first place). > [and don't get me started on CNAME breakage in the wild] https://dougbarton.us/DNS/MX.html :) >>> And to say that we don't have that elsewhere and this is new isn't >>> correct either. 5011 has a number of similar semantics. Consider the >>> revoke bit for the simplest and closest to this case. >> >> Perhaps you could elaborate? It's not clear to me how that case >> applies in the child -> parent signalling direction. > > A revoke bit is only considered "actionable" (IE, revoke it from your > trust storage) if it was signed by the same key that produced the key > with the revoke bit turned on. IE, you can have a "valid" key with the > revoke bit set, but you shouldn't actually act on it because it wasn't > signed by the key itself. See RFC5011, section 2.1, last sentence for > the quick summary. > > The key would still be considered valid by a validator but you shouldn't > act on the knowledge of the data in the key. Sorry, I don't regard that situation as equivalent at all. I understand your reasoning, I just don't agree with it. Doug From dougb@dougbarton.us Tue Apr 23 15:26:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCCB21F8CEB for ; Tue, 23 Apr 2013 15:26: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 MsJSQzBbjIRh for ; Tue, 23 Apr 2013 15:26:46 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3639A21F8C98 for ; Tue, 23 Apr 2013 15:26:46 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47] (unknown [IPv6:2001:470:d:5e7:d199:8326:85b0:8b47]) by dougbarton.us (Postfix) with ESMTPSA id E437222B78 for ; Tue, 23 Apr 2013 22:26:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366756006; bh=zIrV58+JzpsqgAUhcH1X4d4V/mVO6yQvwuxwRloMqro=; h=Date:From:To:Subject:References:In-Reply-To; b=IyEZWl2y1ZRmHOmCrrFZY5JJ7k/P5f8gcXEmLi6efSmoBOW8FhPcTh2Dno3W9qVIa PuGmkQrLK9eqRnmjyWiG/NpOAqhK0wrmAhF6XZXcLHR/dI45tmlMBNL2lG+UqCzpcY +50ozSWMg6WmUEhwCh/O1aUUGnq4DCZt9fbnTVHI= Message-ID: <51770AA5.6010807@dougbarton.us> Date: Tue, 23 Apr 2013 15:26:45 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsop@ietf.org References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0la9opez9v.fsf@wjh.hardakers.net> In-Reply-To: <0la9opez9v.fsf@wjh.hardakers.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 22:26:47 -0000 On 04/23/2013 02:02 PM, Wes Hardaker wrote: > Objecting to the notion without > offering fixes is like saying "I don't want soup to exist because > watching people eat it might make me want it in the future". Wes, that's not only not true, it's at best inflammatory, and IMO ad hominem. As I pointed out in previous posts (where I was loudly shouted down) there is a rather large opportunity cost to creating something that's sort of good, but not likely to be deployed due to fundamental flaws. Arguably there are several opportunity costs involved, but the most important may be that by the protocol wonks claiming to have solved the problem, but the RRR community not deploying the solution because it doesn't meet their needs, we risk a repeat of the same situation we have had in the past where both sides stand in their respective corners pointing fingers and calling each other names. Completely ignore me and my registry/registrar experience if you like. Ed is coming from the perspective of one of the largest registries in the world (read, the intended audience for this draft[1]), and telling you that there are problems with it. It might be worth a listen. Doug [1] I realize that non-TLD parents can also use this mechanism, but that use case is in the margins relative to the utility that it would have at the TLD level. From wjhns1@hardakers.net Tue Apr 23 16:55:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C875021F92FB for ; Tue, 23 Apr 2013 16:55: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 3wHKEtaoZujQ for ; Tue, 23 Apr 2013 16:55:46 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA3221F92BC for ; Tue, 23 Apr 2013 16:55:46 -0700 (PDT) Received: from localhost (wjh.hardakers.net [IPv6:2001:470:1f00:187:f2de:f1ff:fee6:e6e8]) by mail.hardakers.net (Postfix) with ESMTPSA id 5F5DC238B6; Tue, 23 Apr 2013 16:55:45 -0700 (PDT) From: Wes Hardaker To: Doug Barton References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0la9opez9v.fsf@wjh.hardakers.net> <51770AA5.6010807@dougbarton.us> Date: Tue, 23 Apr 2013 16:55:44 -0700 In-Reply-To: <51770AA5.6010807@dougbarton.us> (Doug Barton's message of "Tue, 23 Apr 2013 15:26:45 -0700") Message-ID: <0lhaiwdcov.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop@ietf.org Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 23:55:46 -0000 Doug Barton writes: > On 04/23/2013 02:02 PM, Wes Hardaker wrote: >> Objecting to the notion without >> offering fixes is like saying "I don't want soup to exist because >> watching people eat it might make me want it in the future". > > Wes, that's not only not true, it's at best inflammatory, and IMO ad > hominem. Well, I'll happily retract it then. It certainly wasn't meant in a negative way. I have an amazing amount of respect for Ed as his arguments are always well thought out and well stated. The only argument I have against Ed in this particular discussion is that the resulting solution will be harmful to him since he can simply "not use it". -- Wes Hardaker Parsons From wjhns1@hardakers.net Tue Apr 23 17:03:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB4221F937E for ; Tue, 23 Apr 2013 17:03:53 -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 NFH-5Oy3tGve for ; Tue, 23 Apr 2013 17:03:53 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC621F9377 for ; Tue, 23 Apr 2013 17:03:53 -0700 (PDT) Received: from localhost (wjh.hardakers.net [IPv6:2001:470:1f00:187:f2de:f1ff:fee6:e6e8]) by mail.hardakers.net (Postfix) with ESMTPSA id 7ED7F238B6; Tue, 23 Apr 2013 17:03:52 -0700 (PDT) From: Wes Hardaker To: Doug Barton References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0lip3dezpa.fsf@wjh.hardakers.net> <5176F624.7070309@dougbarton.us> <0lr4i1c5dn.fsf@wjh.hardakers.net> <5177086E.2060301@dougbarton.us> Date: Tue, 23 Apr 2013 17:03:52 -0700 In-Reply-To: <5177086E.2060301@dougbarton.us> (Doug Barton's message of "Tue, 23 Apr 2013 15:17:18 -0700") Message-ID: <0ld2tkdcbb.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop@ietf.org Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:03:53 -0000 Doug Barton writes: >> The key would still be considered valid by a validator but you shouldn't >> act on the knowledge of the data in the key. > > Sorry, I don't regard that situation as equivalent at all. I > understand your reasoning, I just don't agree with it. And that's why we probably need to agree to disagree. They're very similar to me. It's easy, using standard tools today, to create a RRSIG on a DNSKEY with a revoke bit set that signals "something about DNSSEC" to external parties that can't be used because it was signed with the wrong key. I'd been assuming you'd probably have a problem with this too, since it meets the criteria you've been against with CDS as well. Anyway... I'm perfectly fine agreeing to disagree about this. I do think we are understanding each other and much more text won't help get beyond the disagreement, which is not stemming from lack of communication. -- Wes Hardaker Parsons From ajs@anvilwalrusden.com Tue Apr 23 17:07:46 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CD521F9377 for ; Tue, 23 Apr 2013 17:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 Z0emJDSr0ubw for ; Tue, 23 Apr 2013 17:07:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6A83221F93B3 for ; Tue, 23 Apr 2013 17:07:46 -0700 (PDT) Received: from mx1.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 mx1.yitter.info (Postfix) with ESMTPSA id 870728A031 for ; Wed, 24 Apr 2013 00:07:45 +0000 (UTC) Date: Tue, 23 Apr 2013 20:07:43 -0400 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20130424000743.GT15845@mx1.yitter.info> References: <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0la9opez9v.fsf@wjh.hardakers.net> <51770AA5.6010807@dougbarton.us> <0lhaiwdcov.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lhaiwdcov.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 00:07:47 -0000 On Tue, Apr 23, 2013 at 04:55:44PM -0700, Wes Hardaker wrote: > arguments are always well thought out and well stated. The only > argument I have against Ed in this particular discussion is that the > resulting solution will be harmful to him since he can simply "not use > it". I confess that I haven't been following this discussion as closely as I ought (every time I start to try to read the thread, I feel like the thread gets longer). But in the little I've managed to read, it seemed to me that the points Ed was making were (1) that this is an important additional move on the supposed insignificance of the SEP bit, and that is worrisome and (2) if this mechanism were altered slightly, then it could be more generic and therefore more useful. Those both seem to me to be substantive and important points that ought to give us pause about the existing proposal. If I had a hope of getting through Zeno's mail thread this week, I'd try to read it all and respond. Instead I'm just pointing out that a dismissal along the lines of "just don't use it" seems to ignore at least part of the point of reviewing things in the IETF. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From Antoin.Verschuren@sidn.nl Wed Apr 24 04:36:42 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59CE21F8F2C for ; Wed, 24 Apr 2013 04:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] 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 xxE9jMcQZO1g for ; Wed, 24 Apr 2013 04:36:41 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 7474221F8F12 for ; Wed, 24 Apr 2013 04:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=JciFsOut3/ddLEkx+DFsftSbj0j4OOGlNRVqy6UuYRM=; b=j0MNWDrK62rfFIIaYkp8NTxFFFtrHFf16h4q3dwIm0tvt1XR7ew3WbyFQRo0QgmEm4Bf8LvWmUvmkGOxLLTh2fpmlAnaULK0cLb6NOp70Lo3zwZ7TvDqIiy4e05TI7Enj/2PwoEO5C6w1vUg80XJ4sqgw+7MBp0n0azAz+2gcdM= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r3OBaeo0017556-r3OBaeo2017556 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 24 Apr 2013 13:36:40 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 24 Apr 2013 13:36:40 +0200 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 24 Apr 2013 13:36:40 +0200 Message-ID: <5177C3C7.2040704@sidn.nl> Date: Wed, 24 Apr 2013 13:36:39 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 11:36:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 23-04-13 17:18, Edward Lewis schreef: > > For zones that operate under a mandate of the ICANN-style shared > registry model, you can't bypass the registrar. I think this is the essence of why previous attempts to automate technical DNS maintenance were unsuccessful. I actually think it's the ICANN-style translation of the RRR model that is wrong and why we don't go forward. Registrars were invented to distribute administrative load for the registry, and create competition in financial and customer care. Because we started to use that same channel for the technical bootstrapping of a delegation by the absence of a technical channel to do so, ICANN has translated that into it's agreement as not only bootstrapping, but also maintenance of technical data. It is my firm believe that a registrar's role is administrative, and after the sale is done, the registrant controls the technical data. I can see that registrars are happy with the ICANN mistake because they can now control their customers by allowing or disallowing transfer of technical data, but it breaks the technical DNS model if registrars do this based on business rules rather than that it technically has to work parent to child. But registrars couldn't care less, as they are not responsible for any part of the technical infrastructure. It's about power and money, not correctness. Since I'm not a lawyer, nor have lot's of money or trademarks or both, it's almost impossible to bring this to the ICANN agenda, and we are all hostage of this situation. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRd8PHAAoJEDqHrM883AgnIgUIAIKHKJXlgUU3JW/EyGNVa6or 51qqR3FiX68XXClPAWGaDeoEeyiZRMZX/hbj9AB92BIGi0DLKNwj38ouI9HVh+B0 tmRkkyzmOSuNIHVgqYk9n2ngfg0cMZSzas/hf00AAehYq6qEw/glyhSSL+pmljx1 Zb0pVz8l6Hay1sjBpYH3UL8bdeGXQigSOlhYKjJUgy6WJicf61y9/Z1nFkyTJXhe U+QajMr80l9r3TaDS2jLW5cVlT6llZ5p7ACasR86jCKR4sqhXGdkQdpybHsrLvLK UFLSQuZxgc5mUBGp3SyNvmalC7ruKkbCv8FhomSRiNm186GmHPn3kW4ZC8+cWOw= =9NCD -----END PGP SIGNATURE----- From wjhns1@hardakers.net Wed Apr 24 06:18:55 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC25121F9133 for ; Wed, 24 Apr 2013 06:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 gutmDW5Ee4R5 for ; Wed, 24 Apr 2013 06:18:54 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 82EBA21F90A1 for ; Wed, 24 Apr 2013 06:18:54 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:cd3b:dcd2:7894:2703]) by mail.hardakers.net (Postfix) with ESMTPSA id 56F7B27990 for ; Wed, 24 Apr 2013 06:18:45 -0700 (PDT) From: Wes Hardaker To: dnsop@ietf.org Date: Wed, 24 Apr 2013 06:18:45 -0700 Message-ID: <0l7gjs9idm.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [DNSOP] DS transfer requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 13:18:55 -0000 Ed pointed me to a message he wrote [1] and some of the text there triggered my "oh yeah; we need to start with the requirements" bell. I think part of the problem has been we don't have a good list of requirements to compare any given solution to and we're talking around them all because they're not written down (at least in one place). So, stealing bullets from Ed's text and adding some, what are in these lists that shouldn't be, or is in the wrong place and what is missing entirely? There are some I surely suspect people disagree about their location in the list. This is very much a working-document list. * MUST be able tos + Let the child be able to signal a desire to: - add a DS record for a key that is not yet published. - delete a DS record for a key that has never been published. - add a DS recrord for a key that is in use. - delete a DS record for a key that is in use. - add DS records for hashes not previously supported. - add DS records for hashes I am moving away from. + Allow the insertion/deletion action to be done by the parental agent when the child and parent both agree that one of these will trigger a "go" indication: - A child operator indicates "go" via a secondary mechanism (e.g., http) - Immediately after successful data verification within the transfer mechanism + Not change existing DNSSEC validation steps (see [2] below) * SHOULDs if possible + be able to signal using key material + be able to signal using DS hash material + operate on a single record at a time (publish this DS, don't touch the rest) * MAYs + [2] If DNSSEC is used to validate the data, there may be other data verification steps (cryptographic or not) required before a "go" can occur * Explicitly *not* a requirement: + Use the DNS itself as the transport What else? I'm quite sure there are more. (And I'm pseudo-deliberately stopping here to make sure that I don't sound like I'm trying to impose only just my ideas or the ones I pulled from Ed's message). Footnotes: [1] http://www.ietf.org/mail-archive/web/dnsop/current/msg10293.html -- Wes Hardaker Parso ns From Antoin.Verschuren@sidn.nl Wed Apr 24 06:58:01 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB35D21F8E4B for ; Wed, 24 Apr 2013 06:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.684 X-Spam-Level: X-Spam-Status: No, score=0.684 tagged_above=-999 required=5 tests=[AWL=-1.399, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FUZZY_MONEY=2.799, HELO_EQ_IP_ADDR=1.119] 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 bwDPrGxQ4vjG for ; Wed, 24 Apr 2013 06:58:01 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id D2E8021F8E2C for ; Wed, 24 Apr 2013 06:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=CdUR6ijR1MTzoDGDFKPHumEQfPuUi7YetLiweaHgxwc=; b=JRg8YJVpHY9P6x7EiItjdcMoVljEbztwMNVzEGK49zK1ZE+toZeXXlwiWVwsXh5U9gZi3jla0lipUCHGKL+SLfk07FT3xuZkSfqUGRt1MqzAez3me2ZjMPDpaJ02gJSupkovl7NXSq8fH8/OvW/IRhGlIhV/r0t+tRZNI8BjUC4= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r3ODvsPM023911-r3ODvsPO023911 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 24 Apr 2013 15:57:54 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 24 Apr 2013 15:57:54 +0200 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 24 Apr 2013 15:57:54 +0200 Message-ID: <5177E4E1.6020400@sidn.nl> Date: Wed, 24 Apr 2013 15:57:53 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: References: <0l7gjs9idm.fsf@wjh.hardakers.net> In-Reply-To: <0l7gjs9idm.fsf@wjh.hardakers.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [DNSOP] DS transfer requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 13:58:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 24-04-13 15:18, Wes Hardaker schreef: > + operate on a single record at a time (publish this DS, don't > touch the rest) I don't understand the rationale behind this one. Can someone please explain to me? I would think a child knows what "the rest" is at all time, and it's best for him to have that oversight before he changes anything. What am I missing, unknown standby keys? When I change one nameserver in my delegation, I have to fill in the other ones too with most parents. Where is DS different in that it needs this requirement? - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRd+ThAAoJEDqHrM883Agnw7sH/jtoBv0FeyMOKxikhIf/XXi2 WdPa2qIXKMd6OlVAkIKZ5lk5YO+1vOjwJpXdh6YvjrEfcF+dYtuOscWc8WUTIRtq 23/jGUBZPkxQR/KuHDPLbiln3yxMyXL614aqCo1SUwstQm54liobokfxQxArFXzq yx0RHCauHgycsu9mOneJAZZS6OO2+go7NePtj3ZIjJAE7y+jWpV1hl2BDkBKZV5b v6IQ+0gFVSeIXBiSJc+g5X/RDoQr2ISG6wd44GMxJyOXXvyg7HjyJMpCvhS9eudh Yu5xt/N9YNAHP/F0p97t8i9CYdhMzMxxh9jL84f15CGAc3ByDCVQjzFS4OSvXVo= =9fvB -----END PGP SIGNATURE----- From jabley@hopcount.ca Wed Apr 24 06:59:19 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B3F21F85ED for ; Wed, 24 Apr 2013 06:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 ePhdtv6HnAeJ for ; Wed, 24 Apr 2013 06:59:18 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 845EA21F85EB for ; Wed, 24 Apr 2013 06:59:18 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id d10so943045qca.37 for ; Wed, 24 Apr 2013 06:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=xbi3sEJnhgRZk5UYlvzFOZKSEwX0fb3RYhuPi0waAcY=; b=G0B2spZyxiIMl+TpASRlmRIm5ePvFT5cgpbNDtJIfEvcgGDUuQ3/FokrgBWG3G9/RB 1YcZD+3mXrv8R/z7qWTVnwFVzPRTL63jTbZ8/soGOpWIbqm6JDwa543bIYuRXlatCyg8 0SPsD2OdLUqqVgfgHp/4pacP1zXcGbMGr/QG8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=xbi3sEJnhgRZk5UYlvzFOZKSEwX0fb3RYhuPi0waAcY=; b=FBxecdySJavVTxaUdVE8/JiEj2sNgtUuuM6NlUdEqKQI+F5vRe0TRDYdQrDkSbhT8i L6ybWL2Jx9edRfNV53qSIcM8YEM27ljeWMtukJh8b1h2S8lFxqAuykk8EibcCZFZL28j dWpSUFzJrkJIU7NukZXd6ciZL48RXUGoE5WR4/bujKR/2cf9u2i/du6WZHdxHHWko3q0 lveb9S4TmliTu+UOxj1ioNGQtGFrLdavSY5T1+c4HLc/YYtx1Sv9kcwyk1Vlo+56rjot XsZXtc2hAiSy3PfY/mYX9VxjmmwjzReNcV+mMCE1xle8FsZbeB86OI1DcBhQq3jiI+pT cs8w== X-Received: by 10.229.106.89 with SMTP id w25mr8147754qco.36.1366811958018; Wed, 24 Apr 2013 06:59:18 -0700 (PDT) Received: from dh24.r1.hopcount.ca (dh24.r1.hopcount.ca. [199.212.90.24]) by mx.google.com with ESMTPSA id kc7sm3985703qeb.6.2013.04.24.06.59.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 06:59:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: <0l7gjs9idm.fsf@wjh.hardakers.net> Date: Wed, 24 Apr 2013 09:59:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0l7gjs9idm.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnI1wHvmEtL8QZGvZR1HfobiClerSYS5Qpyd4YWPPk24HXlhDYBkVDtGZClBpB6KiM430Er Cc: dnsop@ietf.org Subject: Re: [DNSOP] DS transfer requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 13:59:19 -0000 Hi Wes, On 2013-04-24, at 09:18, Wes Hardaker wrote: > I > think part of the problem has been we don't have a good list of > requirements to compare any given solution to and we're talking around > them all because they're not written down (at least in one place). I like your list. I think it's useful. I think it's also instructive to write down the workflow of how changes = might occur. For example, 1. each polling party (registry, registrar, parent zone operator, = something) maintains a list of child zones that should be polled for CDS = RRSets (which could be "all children", "all customers who have clicked a = button to say they want to be polled", "child zones that we publish a DS = for" or something else) 2. those child zones are polled regularly and the result is occasionally = the construction of change requests for the DS RRSet 3. the polling party satisfies their requirements that a change should = be made (e.g. automatic so long as technical checks pass, signal the = child zone operator and request an out-of-band confirmation, something = else) 4. the change is made in the parent zone (e.g. through direct changes to = a locally-maintained parent zone, EPP signalling to a registry, = something else) Perhaps this could be made more general, but those four steps seem = fairly integral to me, regardless of the shape of the relationship = between child zone operator and parent zone operator. A parent zone operator who wants to generate her own DS RRSets for a = child zone could use the CDS signalling as method to identify a DNSKEY, = could retrieve the DNSKEY RR in question (checking signatures) and = generate their own DS RR for publication. The problem of how to signal = the desire to publish a DS for a key that has not yet been published = remains. It occurred to me that there may be use cases where including a "do not = process before " and "do not process after " on a CDS RR = might be useful, especially if the time taken for the parent to poll is = not predictable. But I haven't thought that through very hard. Joe= From wjhns1@hardakers.net Wed Apr 24 07:30:28 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E563E21F9380 for ; Wed, 24 Apr 2013 07:30:28 -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 WVIykXdevqN8 for ; Wed, 24 Apr 2013 07:30:28 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6621F9354 for ; Wed, 24 Apr 2013 07:30:28 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:cd3b:dcd2:7894:2703]) by mail.hardakers.net (Postfix) with ESMTPSA id 8E22F23BBE; Wed, 24 Apr 2013 07:30:27 -0700 (PDT) From: Wes Hardaker To: Antoin Verschuren References: <0l7gjs9idm.fsf@wjh.hardakers.net> <5177E4E1.6020400@sidn.nl> Date: Wed, 24 Apr 2013 07:30:27 -0700 In-Reply-To: <5177E4E1.6020400@sidn.nl> (Antoin Verschuren's message of "Wed, 24 Apr 2013 15:57:53 +0200") Message-ID: <0l61zc6lx8.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dnsop@ietf.org Subject: Re: [DNSOP] DS transfer requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:30:29 -0000 Antoin Verschuren writes: > Op 24-04-13 15:18, Wes Hardaker schreef: > >> + operate on a single record at a time (publish this DS, don't >> touch the rest) > > I don't understand the rationale behind this one. > Can someone please explain to me? > > I would think a child knows what "the rest" is at all time, and it's > best for him to have that oversight before he changes anything. > What am I missing, unknown standby keys? Well, I agree: you should be able to say "publish this list" and have it be the entire set. But others have indicated (in random conversations) they want to be able to distinctly say do this or that. I suspect that it would be fine to bulk-publish a list for most people, however. But the one caveat is that if we end up adding a hold-down time, and you want to make another (but different) change half way through the hold-down time then your only choice is to restart entirely or wait. But it depends on what the hold down is watching too. The real requirement could probably be better worded to indicate some sort of independence between add/remove operations. -- Wes Hardaker Parsons From fanf2@hermes.cam.ac.uk Thu Apr 25 11:03:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A821F96B0 for ; Thu, 25 Apr 2013 11:03: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=[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 Ok0KVs3g5KBD for ; Thu, 25 Apr 2013 11:03:47 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53721F96AB for ; Thu, 25 Apr 2013 11:03:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59406) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1UVQWF-0006IS-gk (Exim 4.80_167-5a66dd3) (return-path ); Thu, 25 Apr 2013 19:03:43 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UVQWF-0000jf-6e (Exim 4.72) (return-path ); Thu, 25 Apr 2013 19:03:43 +0100 Date: Thu, 25 Apr 2013 19:03:43 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Hoffman In-Reply-To: <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> Message-ID: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <18F8B441-CECF-43C6-9D57-04186362D5DF@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: IETF DNSOP WG , Paul Wouters Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 18:03:48 -0000 Paul Hoffman wrote: > > Except that this thread has brought out many problems in the -01 draft > that will likely result in changes that will make CDS special, not just > like other records. At that point, you will have to decide if having a > CDS record is a better idea than just re-using DS. Re-using DS simply won't work, because you can't specify which side of the zone cut to query when the child and parent are on the same server. >From the point of view of name servers and resolvers, CDS is not special. It is slightly special for signers, and the parent update systems that consumes CDS records need slightly special validators. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From paul@redbarn.org Thu Apr 25 11:14:09 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6408021F9682 for ; Thu, 25 Apr 2013 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.265 X-Spam-Level: X-Spam-Status: No, score=-1.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, 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 dVE1U5Utc5rv for ; Thu, 25 Apr 2013 11:14:08 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id A139B21F9674 for ; Thu, 25 Apr 2013 11:14:08 -0700 (PDT) Received: from [IPV6:2001:559:8000:c9:fdb7:cdab:d19f:2b35] (unknown [IPv6:2001:559:8000:c9:fdb7:cdab:d19f:2b35]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 24C2BEE0C6; Thu, 25 Apr 2013 18:14:08 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----PAE8GQIQEMJ4BP0XX651ZIY8CO6GPY" From: P Vixie Date: Thu, 25 Apr 2013 11:14:06 -0700 To: Tony Finch ,Paul Hoffman Message-ID: Cc: IETF DNSOP WG , Paul Wouters Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 18:14:09 -0000 ------PAE8GQIQEMJ4BP0XX651ZIY8CO6GPY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Note that this is rendezvous information for the management plane and has no protocol significance. A distinct name in the child like _cds._dnssec.@ could hold a DS record without confusion. Similarly, the current DS RR should really have been placed at _ds.child label._dnssec.parentdomain to keep it unambiguously in the parent zone and away from the delegation name. Is to late for the latter but not for the former. Let's not burn a type code just to keep CDS separate. Tony Finch wrote: >Paul Hoffman wrote: >> >> Except that this thread has brought out many problems in the -01 >draft >> that will likely result in changes that will make CDS special, not >just >> like other records. At that point, you will have to decide if having >a >> CDS record is a better idea than just re-using DS. > >Re-using DS simply won't work, because you can't specify which side of >the >zone cut to query when the child and parent are on the same server. > >From the point of view of name servers and resolvers, CDS is not >special. > >It is slightly special for signers, and the parent update systems that >consumes CDS records need slightly special validators. > >Tony. >-- >f.anthony.n.finch http://dotat.at/ >Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at >first. >Rough, becoming slight or moderate. Showers, rain at first. Moderate or >good, >occasionally poor at first. >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------PAE8GQIQEMJ4BP0XX651ZIY8CO6GPY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Note that this is rendezvous information for the management plane and has no protocol significance. A distinct name in the child like _cds._dnssec.@ could hold a DS record without confusion.

Similarly, the current DS RR should really have been placed at _ds.child label._dnssec.parentdomain to keep it unambiguously in the parent zone and away from the delegation name.

Is to late for the latter but not for the former.

Let's not burn a type code just to keep CDS separate.

Tony Finch <dot@dotat.at> wrote:
Paul Hoffman <paul.hoffman@vpnc.org> wrote:

Except that this thread has brought out many problems in the -01 draft
that will likely result in changes that will make CDS special, not just
like other records. At that point, you will have to decide if having a
CDS record is a better idea than just re-using DS.

Re-using DS simply won't work, because you can't specify which side of the
zone cut to query when the child and parent are on the same server.

From the point of view of name servers and resolvers, CDS is not special.

It is slightly special for signers, and the parent update systems that
consumes CDS records need slightly special validators.

Tony.

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------PAE8GQIQEMJ4BP0XX651ZIY8CO6GPY-- From jabley@hopcount.ca Thu Apr 25 12:19:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED6421F969B for ; Thu, 25 Apr 2013 12:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64cIGKMYOxaQ for ; Thu, 25 Apr 2013 12:19:11 -0700 (PDT) Received: from mail-da0-x22e.google.com (mail-da0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F40C621F960B for ; Thu, 25 Apr 2013 12:19:10 -0700 (PDT) Received: by mail-da0-f46.google.com with SMTP id x4so1014738daj.33 for ; Thu, 25 Apr 2013 12:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=2ID3+VQKj1ww9yfjBYggK/M1GpQwF+VfAWDoskjVZKQ=; b=UNd/FwYlKpFrAGoklnq0fhNCgXinoIKVZRGHKstY8WxB82Q7H3sl0R/NjheZMBLk3Z KmLCKPqbfVZt7DrUrw5pLtxKnXvjT9YQJYqsvU6o6wbwkkoaN9zYyNd13QiEmLok/nQy eAMsERxq6JIFmptfjo8skF0e3B9X2H2+90frI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2ID3+VQKj1ww9yfjBYggK/M1GpQwF+VfAWDoskjVZKQ=; b=c6yWzX9hIpxFQ80ms180DuxP5YhyBo1glrG6HZvwSnk1KKPEsxkzNh65e31Cy67zN3 abLSR7ePeEqkqCzlDQfkSD1eTI5XzOyrjGvUhSuMvsN00aVYDvVuuR6gTuQw/xa1LwV2 WINdIcarlhG3dWaYlnYWrES8KdtAPepQD0SEND7kVK8Id8d8nKQdD8Fc8/7MHocRNTuY yDai5pKXr5dQjzGvM4DtntW8bJ6VpRUngIFD1UqmZpzDEP4KWZeGtA+sQKR16vLu9gid Ny8BhLOEuWR7/BwHe0c8Ko46qkkFYjTW5A7oMxv+DYLBHMHNRTdPCwCA6O/rXHYKN2br 6D0w== X-Received: by 10.66.7.228 with SMTP id m4mr27031796paa.173.1366917550722; Thu, 25 Apr 2013 12:19:10 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:100:cc06:295c:ca31:fa1f? ([2001:4900:1042:100:cc06:295c:ca31:fa1f]) by mx.google.com with ESMTPSA id ra9sm9283371pab.16.2013.04.25.12.19.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 12:19:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Abley In-Reply-To: Date: Thu, 25 Apr 2013 15:19:05 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5D8C9796-AB56-4689-B88F-947B23C23A63@hopcount.ca> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> To: P Vixie X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlZ9LqZTlOvRa9xygIJJH8qmG3EQSwgepWmxqMtBHRtsaMjA62FrAF73+SY1hItViDD7MiM Cc: Tony Finch , IETF DNSOP WG , Paul Wouters , Paul Hoffman Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 19:19:11 -0000 On 2013-04-25, at 14:14, P Vixie wrote: > Let's not burn a type code just to keep CDS separate. Note that the type code for CDS has already been assigned, see: http://www.iana.org/assignments/dns-parameters/dns-parameters.xml (it's 59) Joe From marka@isc.org Thu Apr 25 22:50:54 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10421F97C7 for ; Thu, 25 Apr 2013 22:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, MANGLED_FROM=2.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 NSutmWbK+bPx for ; Thu, 25 Apr 2013 22:50:54 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CE6A221F97CF for ; Thu, 25 Apr 2013 22:50:53 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1CD48C94C2; Fri, 26 Apr 2013 05:50:47 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366955453; bh=dtTb44BSUbJohJjL1u5j0VuEGtZYKAOmhXAwbQO8P9c=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=L3k0XrnXd/m5aZnMw41+Oy1cC36dOm1+02Yqzlv/UA+NAGOBLcOqm5HfZCb8IQ4SX 81xaFfr1Sx0trUFjdQwNsEm5Q+nzSGcdlYU4CfEACsVkhIdm3XMBo8GXx9R0ZGEsA7 fctskm+gEwdeGUSNMoycvP6IHRlQDr11G4eF07q0= 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.pao1.isc.org (Postfix) with ESMTPS; Fri, 26 Apr 2013 05:50:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4129:b64c:428a:9207]) (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 B981B216C40; Fri, 26 Apr 2013 05:50:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2FDAB330242E; Fri, 26 Apr 2013 15:50:44 +1000 (EST) To: P Vixie From: Mark Andrews References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> In-reply-to: Your message of "Thu, 25 Apr 2013 11:14:06 -0700." Date: Fri, 26 Apr 2013 15:50:44 +1000 Message-Id: <20130426055044.2FDAB330242E@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Tony Finch , IETF DNSOP WG , Paul Wouters , Paul Hoffman Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 05:50:54 -0000 In message , P Vixie wr ites: > > Note that this is rendezvous information for the management plane and has no > protocol significance. A distinct name in the child like _cds._dnssec.@ could > hold a DS record without confusion. Which doesn't work if you have a DNAME at the zone apex. > Similarly, the current DS RR should really have been placed at _ds.child labe > l._dnssec.parentdomain to keep it unambiguously in the parent zone and away f > rom the delegation name. > > Is to late for the latter but not for the former. > > Let's not burn a type code just to keep CDS separate. If there is going to be zone scraping then the record must be at the zone apex. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul@redbarn.org Thu Apr 25 22:55:41 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52ED21F97C7 for ; Thu, 25 Apr 2013 22:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.964 X-Spam-Level: X-Spam-Status: No, score=-6.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, MANGLED_FROM=2.3, RCVD_IN_DNSWL_HI=-8] 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 at7V1k73Ol-8 for ; Thu, 25 Apr 2013 22:55:41 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [24.104.150.2]) by ietfa.amsl.com (Postfix) with ESMTP id E558321F9080 for ; Thu, 25 Apr 2013 22:55:40 -0700 (PDT) Received: from [IPV6:2001:559:8000:c9:fdb7:cdab:d19f:2b35] (unknown [IPv6:2001:559:8000:c9:fdb7:cdab:d19f:2b35]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id A2379EDAE6; Fri, 26 Apr 2013 05:55:40 +0000 (UTC) (envelope-from paul@redbarn.org) User-Agent: K-9 Mail for Android In-Reply-To: <20130426055044.2FDAB330242E@drugs.dv.isc.org> References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <18F8B441-CECF-43C6-9D57-04186362D5DF@vpnc.org> <20130426055044.2FDAB330242E@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----NP6H4DBHYHKDP709AD3ELBM8Q0LZD3" From: P Vixie Date: Thu, 25 Apr 2013 22:55:37 -0700 To: Mark Andrews Message-ID: <30bd6808-5316-4a2d-8869-ddc30b4122fc@email.android.com> Cc: Tony Finch , IETF DNSOP WG , Paul Wouters , Paul Hoffman Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 05:55:41 -0000 ------NP6H4DBHYHKDP709AD3ELBM8Q0LZD3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mark's right. Mark Andrews wrote: > >In message , P >Vixie wr >ites: >> >> Note that this is rendezvous information for the management plane and >has no >> protocol significance. A distinct name in the child like >_cds._dnssec.@ could >> hold a DS record without confusion. > >Which doesn't work if you have a DNAME at the zone apex. > >> Similarly, the current DS RR should really have been placed at >_ds.child labe >> l._dnssec.parentdomain to keep it unambiguously in the parent zone >and away f >> rom the delegation name. >> >> Is to late for the latter but not for the former. >> >> Let's not burn a type code just to keep CDS separate. > >If there is going to be zone scraping then the record must be at >the zone apex. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------NP6H4DBHYHKDP709AD3ELBM8Q0LZD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mark's right.

Mark Andrews <marka@isc.org> wrote:

In message <d1b81df4-99d1-4e1f-9654-e73a90d196a1@email.android.com>, P Vixie wr
ites:

Note that this is rendezvous information for the management plane and has no 
protocol significance. A distinct name in the child like _cds._dnssec.@ could
hold a DS record without confusion.

Which doesn't work if you have a DNAME at the zone apex.

Similarly, the current DS RR should really have been placed at _ds.child labe
l._dnssec.parentdomain to keep it unambiguously in the parent zone and away f
rom the delegation name.

Is to late for the latter but not for the former.

Let's not burn a type code just to keep CDS separate.

If there is going to be zone scraping then the record must be at
the zone apex.

Mark

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------NP6H4DBHYHKDP709AD3ELBM8Q0LZD3-- From johnsonhammond2@hushmail.com Sat Apr 27 10:05:43 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49CA21F9837 for ; Sat, 27 Apr 2013 10:05:43 -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 bIPC4BQ2LbFx for ; Sat, 27 Apr 2013 10:05:43 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 92F3321F9835 for ; Sat, 27 Apr 2013 10:05:43 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 3E9ED30C44 for ; Sat, 27 Apr 2013 17:05:43 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:05:42 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id C3D6C14DBDE; Sat, 27 Apr 2013 17:05:42 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:05:42 -0400 To: dnsop@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170542.C3D6C14DBDE@smtp.hushmail.com> Subject: [DNSOP] Biggest Fake Conference in Computer Science X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:13:46 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From ed.lewis@neustar.biz Mon Apr 29 11:00:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491F321F9AD4 for ; Mon, 29 Apr 2013 11:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 nVRvZ9teUB1L for ; Mon, 29 Apr 2013 11:00:43 -0700 (PDT) Received: from smtp133.ord.emailsrvr.com (smtp133.ord.emailsrvr.com [173.203.6.133]) by ietfa.amsl.com (Postfix) with ESMTP id 24DB321F9ACE for ; Mon, 29 Apr 2013 11:00:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 9FC6710817C; Mon, 29 Apr 2013 14:00:42 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp29.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id EB556108158; Mon, 29 Apr 2013 14:00:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_F9654B8E-1312-4713-B565-8465C76479F2" From: Edward Lewis In-Reply-To: <0la9opez9v.fsf@wjh.hardakers.net> Date: Mon, 29 Apr 2013 14:00:41 -0400 Message-Id: References: <81F68121-6004-4441-B065-20588721BDED@neustar.biz> <0ld2tra3kd.fsf@wjh.hardakers.net> <0lip3i1r7q.fsf@wjh.hardakers.net> <71669929-3664-4781-ADF3-53E7DFBF678E@ogud.com> <6EF6DF48-EBA9-484E-81C1-5371A25F7332@neustar.biz> <0l8v4afhjj.fsf@wjh.hardakers.net> <0la9opez9v.fsf@wjh.hardakers.net> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 18:00:48 -0000 --Apple-Mail=_F9654B8E-1312-4713-B565-8465C76479F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Another omnibus response to a few. (Had to step away for a few days.) On Apr 23, 2013, at 17:02, Wes Hardaker wrote: > - Realize that CDS is likely to go forward because a lot of people = like it and: >=20 > - [ ] choose to ignore it because it doesn't fit your desires >=20 > - [ ] offer concrete suggestions to change it so it does fit your > needs (without removing the features that everyone else keeps = saying > they want (in-band acceptance)) I think that the above statement is indicative of what I see wrong in = the IETF process. Sorry that this is off-topic, but I feel the need to = pick this out as something to look out for in the consideration of the = proposal. "A lot of people like it" - but that is not consensus. And, I can't say = that I even agree with "a lot" and "like it". What is "a lot" when you = consider that very, very few people have ever recorded a public opinion = on this? I haven't counted (to be fair) but I bet it is less than 25. = We had more than that in the DNSOP meeting in Orlando. To go quickly to = the point, there are a lot of people in the DNS industry that don't = participate in the IETF, so "a lot" is kind of a weak bar. As for "like = it", this is a first draft and I'd say I like it because it has = potential. Olafur has a framework for going forward which is good. As = for an concrete alternative - if I'm not mistaken, this is a working = group. I have ideas, but because I time slice through life's issues, I = don't want to fix my mind up with a solution that I'd fall in love with. I have in the past offered up criteria for opening this up. But I don't = have a solution. I'm trying to avoid having an opinion, because I don't = think the problem is completely understood. Sorry for this rant, took = more time than I thought. > - [ ] Objecting and then pushing the appeal as far you can make it go > and stomp your feet really loudly on the ietf@ mailing list Frankly, I really don't have even just the time to think about that much = less launch a complaint. If the IETF promotes a document, I let it go. = I honestly don't care that much about the process. There are a lot of = bad documents out there already, what's one more? Well, in this case, = if the proposal isn't general, you've added one more obstacle to a = general solution. I do care about engineering something useful, = document quality is not what I'm going to bark about - just not enough = time. On Apr 23, 2013, at 20:07, Andrew Sullivan wrote: > ... (1) that this is an > important additional move on the supposed insignificance of the SEP > bit, and that is worrisome and (2) if this mechanism were altered > slightly, then it could be more generic and therefore more useful. Exactly. > Instead I'm just pointing out that a dismissal along > the lines of "just don't use it" seems to ignore at least part of the > point of reviewing things in the IETF. Exactly. (I guess this is more of +1 to Andrew's message.) On Apr 24, 2013, at 7:36, Antoin Verschuren wrote: > I actually think it's the ICANN-style translation of the RRR model > that is wrong and why we don't go forward. That's not a a helpful response to the problem. Whether you are right = or not, you can't wave a wand and see requirements go away. No matter = what one feels about a set of business rules, you have to deal with = anything that others want to participate in. I have a hard time seeing = how a model that accounts for 100's of millions of domain registrations = can be so flawed it can't work - especially when there are, what 250 = million total domain registrations? I"m just saying - you can't = discount something that is so prevalent even if it is flawed. On Apr 26, 2013, at 1:55, P Vixie wrote: > Mark's right. Not so much as a reply to that but a reply to the alternate engineering = solutions and a reason to keep an open mind. If this were easily = solved, it would have been in RFC 4034 and RFC 4035. Recall that in = 2002-2003 (when the work behind the RFCs happened) we did not have the = experiences we have now. And EPP had just started rolling out, etc.... Pretty much we need to have something in the CDS record at the apex of = the zone. And to make this work really well, we have to figure out how = I'd get a DS record for an unpublished DNSKEY into a zone like .NL = (Antoin's - well, not his personally) that wants keys to work on, not DS = records. To hark back to Wes, I don't have answer for that, I don't = want to propose a solution - like, hey Antoin, you're wrong, use DS = instead - that would prevent Antoin from operating under his model. I = can see having CDS be used to indicate what DNSKEY Antoin would have to = pull - if the key is in the DNS. And yes, there is a DS record in the = root zone (as of last time I checked) that pointed to an un-published = DNSKEY. And it is not one I put there just to mess with Antoin's model. = ;) I'm looking forward to the next document on this, and we can continue = working on it. Problems are solvable, even more so when the problem = statement is clear and agreed upon. And - the problem statement might = morph as we progress. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_F9654B8E-1312-4713-B565-8465C76479F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
- Realize that CDS is likely to go forward because a = lot of people like it and:

 - [ ] choose to ignore it = because it doesn't fit your desires

 - [ ] offer concrete = suggestions to change it so it does fit your
=        needs (without removing the = features that everyone else keeps saying
=        they want (in-band = acceptance))

I think that the = above statement is indicative of what I see wrong in the IETF process. =  Sorry that this is off-topic, but I feel the need to pick this out = as something to look out for in the consideration of the = proposal.

"A lot of people like it" - but that = is not consensus.  And, I can't say that I even agree with "a lot" = and "like it".  What is "a lot" when you consider that very, very = few people have ever recorded a public opinion on this?  I haven't = counted (to be fair) but I bet it is less than 25.  We had more = than that in the DNSOP meeting in Orlando.  To go quickly to the = point, there are a lot of people in the DNS industry that don't = participate in the IETF, so "a lot" is kind of a weak bar.  As for = "like it", this is a first draft and I'd say I like it because it has = potential.  Olafur has a framework for going forward which is good. =  As for an concrete alternative - if I'm not mistaken, this is a = working group.  I have ideas, but because I time slice through = life's issues, I don't want to fix my mind up with a solution that I'd = fall in love with.

I have in the past offered = up criteria for opening this up.  But I don't have a solution. =  I'm trying to avoid having an opinion, because I don't think the = problem is completely understood.  Sorry for this rant, took more = time than I thought.

 - [ ] = Objecting and then pushing the appeal as far you can make it go
=        and stomp your feet really = loudly on the ietf@ mailing = list

Frankly, I really don't = have even just the time to think about that much less launch a = complaint.  If the IETF promotes a document, I let it go.  I = honestly don't care that much about the process.  There are a lot = of bad documents out there already, what's one more?  Well, in this = case, if the proposal isn't general, you've added one more obstacle to a = general solution.  I do care about engineering something useful, = document quality is not what I'm going to bark about - just not enough = time.

On Apr 23, 2013, at 20:07, Andrew = Sullivan wrote:

... (1) that this is an
important additional move = on the supposed insignificance of the SEP
bit, and that is worrisome = and (2) if this mechanism were altered
slightly, then it could be = more generic and therefore more = useful.

Exactly.

 Instead I'm just pointing out that a dismissal = along
the lines of "just don't use it" seems to ignore at least part = of the
point of reviewing things in the = IETF.

Exactly.

(I guess this is more of +1 to Andrew's = message.)

On Apr 24, 2013, at 7:36, = Antoin Verschuren wrote:

I = actually think it's the ICANN-style translation of the RRR model
that = is wrong and why we don't go = forward.

That's not a a helpful = response to the problem.  Whether you are right or not, you can't = wave a wand and see requirements go away.  No matter what one feels = about a set of business rules, you have to deal with anything that = others want to participate in.  I have a hard time seeing how a = model that accounts for 100's of millions of domain registrations can be = so flawed it can't work - especially when there are, what 250 million = total domain registrations?  I"m just saying - you can't discount = something that is so prevalent even if it is = flawed.

On Apr 26, 2013, at 1:55, P Vixie = wrote:

Mark's = right.

Not so much as a reply = to that but a reply to the alternate engineering solutions and a reason = to keep an open mind.  If this were easily solved, it would have = been in RFC 4034 and RFC 4035.  Recall that in 2002-2003 (when the = work behind the RFCs happened) we did not have the experiences we have = now.  And EPP had just started rolling out, = etc....

Pretty much we need to have something = in the CDS record at the apex of the zone.  And to make this work = really well, we have to figure out how I'd get a DS record for an = unpublished DNSKEY into a zone like .NL (Antoin's - well, not his = personally) that wants keys to work on, not DS records.  To hark = back to Wes, I don't have answer for that, I don't want to propose a = solution - like, hey Antoin, you're wrong, use DS instead - that would = prevent Antoin from operating under his model.  I can see having = CDS be used to indicate what DNSKEY Antoin would have to pull - if the = key is in the DNS.  And yes, there is a DS record in the root zone = (as of last time I checked) that pointed to an un-published DNSKEY. =  And it is not one I put there just to mess with Antoin's model. = ;)

I'm looking forward to the next document on = this, and we can continue working on it.  Problems are solvable, = even more so when the problem statement is clear and agreed upon. =  And - the problem statement might morph as we = progress.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_F9654B8E-1312-4713-B565-8465C76479F2-- From ed.lewis@neustar.biz Mon Apr 29 11:07:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9058121F93B7 for ; Mon, 29 Apr 2013 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.751 X-Spam-Level: X-Spam-Status: No, score=-101.751 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 L-gZ8yXAbu7o for ; Mon, 29 Apr 2013 11:07:48 -0700 (PDT) Received: from smtp133.ord.emailsrvr.com (smtp133.ord.emailsrvr.com [173.203.6.133]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD821F9868 for ; Mon, 29 Apr 2013 11:07:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 165B6108139; Mon, 29 Apr 2013 14:07:45 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp29.relay.ord1a.emailsrvr.com (Authenticated sender: edlewis-AT-ogud.com) with ESMTPSA id D0A17108123; Mon, 29 Apr 2013 14:07:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B3EF6B04-724B-4DD1-8BBD-AAB72CD47F07" From: Edward Lewis In-Reply-To: <5177E4E1.6020400@sidn.nl> Date: Mon, 29 Apr 2013 14:07:44 -0400 Message-Id: <4FDA5B43-2E50-459C-AB58-6576FACA7832@neustar.biz> References: <0l7gjs9idm.fsf@wjh.hardakers.net> <5177E4E1.6020400@sidn.nl> To: IETF DNSOP WG X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [DNSOP] DS transfer requirements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 18:07:53 -0000 --Apple-Mail=_B3EF6B04-724B-4DD1-8BBD-AAB72CD47F07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 24, 2013, at 9:57, Antoin Verschuren wrote: >>=20 >> + operate on a single record at a time (publish this DS, don't >> touch the rest) >=20 > I don't understand the rationale behind this one. > Can someone please explain to me? In the sense that having to tell the parent that "I want these 10 DS = records now" and then later "I want these 9 DS records now", resulting = in the transfer of 19 records. I could say, "please delete this one = record now." I.e., less to transfer. The tradeoff is whether you value the mythical property of idempotent = operations (where an unintentional repeated request has no bearing) or = value minimizing verbiage exchanged. Idempotent operations has appeal, but having lived through it, it's not = "all that." The alternative approach means the child has to maintain = state and an eye on the parent. Anyway, that's a rationale behind it. Not a judgement. = -=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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_B3EF6B04-724B-4DD1-8BBD-AAB72CD47F07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

+ operate on a = single record at a time (publish this DS, = don't
touch the = rest)

I don't understand the rationale behind this = one.
Can someone please explain to = me?

In the sense that having to = tell the parent that "I want these 10 DS records now" and then later "I = want these 9 DS records now", resulting in the transfer of 19 records. =  I could say, "please delete this one record now."  I.e., less = to transfer.

The tradeoff is whether you value = the mythical property of idempotent operations (where an unintentional = repeated request has no bearing) or value minimizing verbiage = exchanged.

Idempotent operations has appeal, but = having lived through it, it's not "all that."  The alternative = approach means the child has to maintain state and an eye on the = parent.

Anyway, that's a rationale behind it. =  Not a judgement.

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

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_B3EF6B04-724B-4DD1-8BBD-AAB72CD47F07-- From bdickson@verisign.com Mon Apr 29 12:01:32 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F7121F9ABF for ; Mon, 29 Apr 2013 12:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Q-PNJMeUfnWk for ; Mon, 29 Apr 2013 12:01:26 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 634F021F930A for ; Mon, 29 Apr 2013 12:01:16 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUX7DfDAa4YfexrQ3f5rXFbyuJ2Q3viwI@postini.com; Mon, 29 Apr 2013 12:01:17 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r3TJ1Cdo021572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Apr 2013 15:01:12 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 29 Apr 2013 15:01:12 -0400 From: "Dickson, Brian" To: Edward Lewis , IETF DNSOP WG Thread-Topic: [DNSOP] Thoughts on CDS Thread-Index: AQHOQGXh7WPPSRtEDkeKohhxOYc2Z5jtyS6A///N2AA= Date: Mon, 29 Apr 2013 19:01:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CDA438AF9F26bdicksonverisigncom_" MIME-Version: 1.0 Subject: Re: [DNSOP] Thoughts on CDS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 19:01:32 -0000 --_000_CDA438AF9F26bdicksonverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ed Lewis wrote: And to make this work really well, we have to figure out how I'd get a DS = record for an unpublished DNSKEY into a zone like .NL (Antoin's - well, not= his personally) that wants keys to work on, not DS records. To hark back = to Wes, I don't have answer for that, I don't want to propose a solution - = like, hey Antoin, you're wrong, use DS instead - that would prevent Antoin = from operating under his model. I can see having CDS be used to indicate w= hat DNSKEY Antoin would have to pull - if the key is in the DNS. Okay, here's an open question (as in, if anyone knows, please chime in): Is it possible/feasible/easy, to use DNSKEYs as public/private crypto tools= ' keys, generally? E.g. If I have a public key (from a DNSKEY), say for my zone's parent-zone'= s ZSK, could I encrypt something (like a public DNSKEY value, which has not= been published), and have the parent-zone's operator decrypt it (with thei= r private key(s), either offline, online, or using an HSM which performs de= cryption without exposing the private keys)? This would avoid the act of pu= blishing the DNSKEY, while still having the general mechanism of using DNS = to publish CDS data. The DNSKEY is transferrable only to the parent, presum= ing no leakage of private keys on the parent's side, so the DNSKEY remains = "unpublished", yet Antoin's model should still work (albeit with the additi= on of "encrypt" to the web-form). If so, then I think this may be a feasible solution: Have support for encrypted DNSKEY data, with fields indicating signer name = (parent zone apex), key tag and algorithm. NB =96 the parent's DNSKEY used for encrypting the child's DNSKEY, might po= ssibly be used ONLY for encrypting/decrypting CDS data, I.e. be yet another= member of the DNSKEY set, but be neither a ZSK nor a KSK. Maybe we could h= ave another bit assigned to signal this particular use/purpose? Thoughts? Brian --_000_CDA438AF9F26bdicksonverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8A4FA6007E2B824181DC779D857774FE@verisign.com> Content-Transfer-Encoding: quoted-printable
Ed Lewis wrote:
 And to make this work really well, we have to figure out how I'd= get a DS record for an unpublished DNSKEY into a zone like .NL (Antoin's -= well, not his personally) that wants keys to work on, not DS records. &nbs= p;To hark back to Wes, I don't have answer for that, I don't want to propose a solution - like, hey Antoin, you're wr= ong, use DS instead - that would prevent Antoin from operating under his mo= del.  I can see having CDS be used to indicate what DNSKEY Antoin woul= d have to pull - if the key is in the DNS. 

Okay, here's an open question (as in, if anyone knows, please chime in= ):

Is it possible/feasible/easy, to use DNSKEYs as public/private crypto = tools' keys, generally?

E.g. If I have a public key (from a DNSKEY), say for my zone's parent-= zone's ZSK, could I encrypt something (like a public DNSKEY value, which ha= s not been published), and have the parent-zone's operator decrypt it (with= their private key(s), either offline, online, or using an HSM which performs decryption without exposing the pri= vate keys)? This would avoid the act of publishing the DNSKEY, while still = having the general mechanism of using DNS to publish CDS data. The DNSKEY i= s transferrable only to the parent, presuming no leakage of private keys on the parent's side, so the DNSKEY r= emains "unpublished", yet Antoin's model should still work (albei= t with the addition of "encrypt" to the web-form).

If so, then I think this may be a feasible solution:

Have support for encrypted DNSKEY data, with fields indicating signer = name (parent zone apex), key tag and algorithm.

NB =96 the parent's DNSKEY used for encrypting the child's DNSKEY, mig= ht possibly be used ONLY for encrypting/decrypting CDS data, I.e. be yet an= other member of the DNSKEY set, but be neither a ZSK nor a KSK. Maybe we co= uld have another bit assigned to signal this particular use/purpose?

Thoughts?

Brian
--_000_CDA438AF9F26bdicksonverisigncom_--