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 20:54 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 04E6D129BA2 for <dnsop@ietfa.amsl.com>; Wed, 31 May 2017 13:54:19 -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 SWq8l1nVgTBa for <dnsop@ietfa.amsl.com>; Wed, 31 May 2017 13:54:17 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3E5124B0A for <dnsop@ietf.org>; Wed, 31 May 2017 13:54:17 -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 13:54:15 -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 13:54:14 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "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//98VtgACPvoCACKm9AIAAE2gA
Date: Wed, 31 May 2017 20:54:14 +0000
Message-ID: <988BC4E0-4695-4E84-9D1A-1C05CFFF94B4@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> <B5F083EA-D82F-4502-AF3B-46CF46089203@icann.org>
In-Reply-To: <B5F083EA-D82F-4502-AF3B-46CF46089203@icann.org>
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_3579094454_811668187"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RgA-Hpt9C5MqoPQ0kOYnKTaQx2Q>
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 20:54:19 -0000

Answering my own question...relooking at my data, I see two TLD operators (running a total of 4 zones) revoking KSK's on a regular basis.

On 5/31/17, 15:44, "Edward Lewis" <edward.lewis@icann.org> wrote:

    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