Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

Michael StJohns <msj@nthpermutation.com> Mon, 20 March 2017 16:18 UTC

Return-Path: <msj@nthpermutation.com>
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 C73E41294D8 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 09:18:27 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 XkQF1NNvt62W for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 09:18:25 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2D312773A for <dnsop@ietf.org>; Mon, 20 Mar 2017 09:18:25 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id n21so110986085qta.1 for <dnsop@ietf.org>; Mon, 20 Mar 2017 09:18:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=4DRqm2b7zyR+6rwfDVcnyrsmV436zUHPZsdECV7gwMs=; b=qqwPyq2Fs7b1+4Fpl7/OTNsIfGDeu3OnEP5EyX0JLDZ44FogPN12CsmqqIWhEdOHkR y8oSqnOlwqoOJgb/L2lOc7a8AtL/Bwmykd8ZJqbIxtv+fXMb6YqNvJYXbDGtgGzlHCDN p21dUIAzZeJfC4RPqc9/NLN9CR/red/K5vFIpn+JXjpMxJPZ3YXYzMuFq3Tn2rJTTJ1p JxNF4+mGlCxFRTrsi/9hyOBYt6+snYF3l45BGuru0iphCtUyuV9A4NdZfI34lUsF3bHM wyjmJiamFEwy+rOTDdS7B0zrJS2GJ5yEskG+HZCvZd1twSIr6oQD7wsaqMMyResZMgpg TphQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=4DRqm2b7zyR+6rwfDVcnyrsmV436zUHPZsdECV7gwMs=; b=sgBHFsmIQWIeNOecUA09dxOHJKnt2KOgB36qC5YidPIvbYJrf3nahqdEEPli0mqHu6 jYy+C5+6QPAwd2H1HS0vNS3AcS5w/V8ZCznt8iJxc3BAIK140PqxzDMGvy1GdCyi2EAe DYV4g6UHwLe0z3sMusfy9ouIn84PC3PUdQZyTdp+QPDloi6WDo+bkSF6Mer8LIhVRceT LBl9zH2l9CL9iSeb9u1KBJaC0+BBYZNKUPLmHer8jsl27Izrq84Xf0abp4sYM0KBnIzX +GsdGZAXB1p6a74qcglKDPmZ/9NBdM8ylMiNmWn8KY8C9uEz624GzesoQuIhPuNdBzcW xgLg==
X-Gm-Message-State: AFeK/H0IiCtZRA6ek/VIZKmEPty4OTBrG1gWk4656G9MpZf0qE67LpUDR93PwEmJZ2hTdg==
X-Received: by 10.200.49.66 with SMTP id h2mr27443145qtb.252.1490026704074; Mon, 20 Mar 2017 09:18:24 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:513c:7598:48a0:ae76:31c9? ([2601:152:4400:513c:7598:48a0:ae76:31c9]) by smtp.gmail.com with ESMTPSA id m62sm12671286qkf.31.2017.03.20.09.18.22 for <dnsop@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 09:18:23 -0700 (PDT)
To: dnsop@ietf.org
References: <CADyWQ+ECthEmWxDbc717BMQo_=PMxz9M0vthDxjOpNW_M7XPTw@mail.gmail.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <f1bfbde5-8776-679c-65fe-31c6e6dfc6d6@nthpermutation.com>
Date: Mon, 20 Mar 2017 12:18:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CADyWQ+ECthEmWxDbc717BMQo_=PMxz9M0vthDxjOpNW_M7XPTw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3AA2AECDB3C032D078117434"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Q4I4PLV2FrAFUDKSogAEJuF02Qo>
Subject: Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-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: Mon, 20 Mar 2017 16:18:28 -0000

On 3/16/2017 3:16 AM, tjw ietf wrote:
> All
>
> We've had a lot of WG discussion on this, and it seems relevant to do 
> a formal call for adoption.   If there are outstanding issues raised 
> during the CfA, time in Chicago will be set aside to have those 
> discussions.
>
>
> This starts a Call for Adoption for: 
>  draft-hardaker-rfc5011-security-considerations
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/
>
> Please review this draft to see if you think it is suitable for 
> adoption by DNSOP, and comments to the list, clearly stating your view.

I've no objection to placing this as a WG item for work.

However, as I've indicated to Wes and Warren, it's currently missing the 
point.

Here's the alternate abstract text I proposed to them:

> This document describes the math behind the minimum time-length a DNS 
> zone publisher must wait after publishing a new trust anchor before 
> having a reasonable belief that all operational, well-behaved 5011 
> clients have installed that new trust anchor at their zone trust 
> point.  As publisher guidance, this is also the minimum time the 
> publisher should wait before revoking the complete set of previously 
> published/installed trust anchors and depending on the newly published 
> trust anchor as the sole point of trust and the minimum time the 
> publisher should continuing publishing a revoked key (and its 
> signature) after revocation.

The timing issue you need to resolve is not when you begin providing 
RRSigs with the new key, but when you revoke all of the other keys at 
the trust point.

The document as currently drafted still assumes there is only one trust 
anchor key as steady state.  That's a) a bad assumption, and b) a bad 
operational policy.

Mike


>
> Please also indicate if you are willing to contribute text, review, etc.
>
> If there are
>
> This call for adoption ends: 30 March 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop