Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

Shane Kerr <shane@time-travellers.org> Mon, 06 February 2017 12:12 UTC

Return-Path: <shane@time-travellers.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 2EBC8129D00 for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 04:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PYE_xsf6UWaq for <dnsop@ietfa.amsl.com>; Mon, 6 Feb 2017 04:12:04 -0800 (PST)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17292129536 for <dnsop@ietf.org>; Mon, 6 Feb 2017 04:12:03 -0800 (PST)
Received: from [2001:470:78c8:2:6ce0:82ed:b11b:7f37] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1cai9g-0007Vv-BE; Mon, 06 Feb 2017 12:12:24 +0000
Date: Mon, 6 Feb 2017 13:11:53 +0100
From: Shane Kerr <shane@time-travellers.org>
To: Warren Kumari <warren@kumari.net>
Message-ID: <20170206131153.52329a04@pallas.home.time-travellers.org>
In-Reply-To: <CAHw9_iKYkZNG=JLSUbCVpsrmkupFM6635eMHJsQXDWcLJmLgKQ@mail.gmail.com>
References: <148616456120.4133.8494448927223938318.idtracker@ietfa.amsl.com> <CAHw9_iKYkZNG=JLSUbCVpsrmkupFM6635eMHJsQXDWcLJmLgKQ@mail.gmail.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/yIN72=0uBg8/MAMRMg2G2hX"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SKoxuP0Gt5A-Dnj5IPX10awSy-Y>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 06 Feb 2017 12:12:07 -0000

Warren,

I am still wondering about the:

   3 * (DNSKEY RRSIG Signature Validity) / 2

Term in the draft, which I see survived the update.

Why is this not just the DNSKEY RRSIG Signature Validity? In principle
once the signature has expired it cannot be used to replay the old
DNSKEY RRset right?

Cheers,

--
Shane

At 2017-02-03 21:14:03 -0500
Warren Kumari <warren@kumari.net> wrote:

> Hi all,
> 
> Was and I have updated this document to make it clearer and more
> readable. Please take a read and let us know if any parts are unclear,
> if you have any other feedback, etc.
> 
> Is this close to done?
> W
> 
> On Fri, Feb 3, 2017 at 6:29 PM,  <internet-drafts@ietf.org> wrote:
> >
> > A new version of I-D, draft-hardaker-rfc5011-security-considerations-02.txt
> > has been successfully submitted by Warren Kumari and posted to the
> > IETF repository.
> >
> > Name:           draft-hardaker-rfc5011-security-considerations
> > Revision:       02
> > Title:          Security Considerations for RFC5011 Publishers
> > Document date:  2017-02-02
> > Group:          Individual Submission
> > Pages:          8
> > URL:            https://www.ietf.org/internet-drafts/draft-hardaker-rfc5011-security-considerations-02.txt
> > Status:         https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/
> > Htmlized:       https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-02
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardaker-rfc5011-security-considerations-02
> >
> > Abstract:
> >    This document describes the math behind the minimum time-length that
> >    a DNS zone publisher must wait before using a new DNSKEY to sign
> >    records when supporting the RFC5011 rollover strategies.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >  
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>