IETF Logo Mail Archive

Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt

Edward Lewis <edward.lewis@icann.org> Wed, 31 May 2017 19:44 UTC

Return-Path: <edward.lewis@icann.org>
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 DE6B7128B44 for <dnsop@ietfa.amsl.com>; Wed, 31 May 2017 12:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nZqzeJyb5Jb for <dnsop@ietfa.amsl.com>; Wed, 31 May 2017 12:44:50 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B11128ACA for <dnsop@ietf.org>; Wed, 31 May 2017 12:44:50 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 31 May 2017 12:44:48 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 31 May 2017 12:44:47 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Michael StJohns <msj@nthpermutation.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt
Thread-Index: AQHS1MftY4O5fSLaF0OP5Dkuz6lW3qIEArj2gAG+IQCAACNYAP//98VtgACPvoCACKm9AA==
Date: Wed, 31 May 2017 19:44:46 +0000
Message-ID: <B5F083EA-D82F-4502-AF3B-46CF46089203@icann.org>
References: <149560445570.28419.14767177653896917226@ietfa.amsl.com> <33126a41-8fb6-b2d9-8d1d-2d6a9a8cf0d5@comcast.net> <ybl60gq9bq2.fsf@wu.hardakers.net> <8AF24B97-BB51-4A1C-8FF2-C53B32552ACA@vpnc.org> <401caf02-5631-de42-489c-8ca3346456a4@nthpermutation.com> <20170526015222.C1FE979B8C4F@rock.dv.isc.org> <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com>
In-Reply-To: <2e27b3d9-04f7-c063-1b3a-699a41fa32df@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3579090286_1704327394"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fc2-ln-eT43G2-qdqRkKOQ9m02w>
Subject: Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2017 19:44:52 -0000

Coming late to this thread, I have a question.

How many operational instances of "Automated Updates" [RFC 5011] are there?

Besides the root zone KSK, I don't know of any.  I do some monitoring of DNSSEC practices, years ago I noticed one TLD appearing to follow RFC 5011's semantics.  But in recent looks that TLD seems to have abandoned the practice (I've never made contact to confirm).  In a scan of second-level names a month ago, I found only traces of revoked keys (KSK and ZSK!).

I ask because of the issues raised in the thread regarding the number of keys assumed in the operation.  Automated Updates apparently (to me) was defined with more than one active secure entry point in mind, but in practice, the only operating example I've witnessed of Automated Updates relies on a single active secure entry point.

I've asked around (tool developers) and, so far, no other examples have popped up.  I'm sure there are some out there.

v2.23.0 | Report a Bug | By Email