Re: [DNSOP] requesting WGLC for 5011-security-considerations
Wes Hardaker <wjhns1@hardakers.net> Wed, 12 July 2017 17:35 UTC
Return-Path: <wjhns1@hardakers.net>
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 660591316A8 for <dnsop@ietfa.amsl.com>; Wed, 12 Jul 2017 10:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 SRBuRL2oj3T7 for <dnsop@ietfa.amsl.com>; Wed, 12 Jul 2017 10:35:30 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6DC131549 for <dnsop@ietf.org>; Wed, 12 Jul 2017 10:35:30 -0700 (PDT)
Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 92FB2251FD; Wed, 12 Jul 2017 10:35:29 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: Michael StJohns <msj@nthpermutation.com>, dnsop@ietf.org
References: <ybl4luqq05v.fsf@w7.hardakers.net> <CANeU+ZBzP+0REnZf0=_t60oXD_oA1nbYMRGcoFQ221buJb8YBw@mail.gmail.com> <ybly3s2le1m.fsf@w7.hardakers.net> <CANeU+ZD7NF07hZdsQT74bZar41dW6i2k6zaNvVnbRg0WYP4tMQ@mail.gmail.com> <yblmv8il906.fsf@w7.hardakers.net> <8c53d2b7-afe7-fe83-27b0-11297d896ad7@nthpermutation.com> <ybl1sptlazr.fsf@w7.hardakers.net> <a1af5a54-8d50-698d-71e2-87f6dbeb9ca2@nthpermutation.com> <yblo9sxpfb8.fsf@wu.hardakers.net>
Date: Wed, 12 Jul 2017 10:35:28 -0700
In-Reply-To: <yblo9sxpfb8.fsf@wu.hardakers.net> (Wes Hardaker's message of "Thu, 06 Jul 2017 11:53:47 -0700")
Message-ID: <yblh8yhmucf.fsf@wu.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dkJuSJBaNh2-mHMX_2rjPy2GvGc>
Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations
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, 12 Jul 2017 17:35:31 -0000
Mike, > The value in 6 regardless of what it is is the wrong value for > revocation. revocationPublicationWaitTime is basically > EarliestDateAttackFails + queryInterval + slop. Revocations take > place immediately. You can delay them only as long as you have old > valid signed RRSets. So in short, the advice in 5011 section 6.6 step 3: 3. After 30 days, stop publishing the old, revoked keys and remove any corresponding DS records in the parent. Has nothing to do with a needed wait time (because keys are revoked immediately) but rather the above 30 days is really just a suggested time for operational practice? In 2.4.2 you have: The remove hold-down time is 30 days. This parameter is solely a key management database bookeeping parameter. Failure to remove information about the state of defunct keys from the database will not adversely impact the security of this protocol, but may end up with a database cluttered with obsolete key information. Which seems to back this up (though I'm not convinced that there is no security ramifications of having old trust anchors around; else why delete them?) So in the 5011-security-considerations draft, I agree with your point that the right amount of time to wait should be changed to replayTime + queryInterval + slop. Thanks for pointing that out. (though it's worth noting that replayTime + queryInterval can be longer than 30 days). -- Wes Hardaker USC/ISI
- [DNSOP] requesting WGLC for 5011-security-conside… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Paul Hoffman
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Matthijs Mekking
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker
- Re: [DNSOP] requesting WGLC for 5011-security-con… Matthijs Mekking
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Michael StJohns
- Re: [DNSOP] requesting WGLC for 5011-security-con… Wes Hardaker