[secdir] Secdir review of draft-ietf-dnsop-dnssec-key-timing-06

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Thu, 18 December 2014 03:21 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7B1A0103; Wed, 17 Dec 2014 19:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 p7IfTxNGr1Fc; Wed, 17 Dec 2014 19:21:13 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3071A010C; Wed, 17 Dec 2014 19:21:12 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQE90749; Thu, 18 Dec 2014 03:21:10 +0000 (GMT)
Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 18 Dec 2014 03:21:09 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.153]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0158.001; Thu, 18 Dec 2014 11:21:03 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "Org Secdir@Ietf." <secdir@ietf.org>, "Org Iesg@Ietf." <iesg@ietf.org>, "draft-ietf-dnsop-dnssec-key-timing.all@tools.ietf.org" <draft-ietf-dnsop-dnssec-key-timing.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-dnsop-dnssec-key-timing-06
Thread-Index: AQHQGnGn+Egv1346o0inbQdvPuNZig==
Date: Thu, 18 Dec 2014 03:21:03 +0000
Message-ID: <8618C668-2030-4CA9-B190-329C7FD630C6@huawei.com>
References: <5491E390.1010809@si6networks.com>
In-Reply-To: <5491E390.1010809@si6networks.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/zMxzzyMPGPWqiFJCgE_YaAns5Oc
Subject: [secdir] Secdir review of draft-ietf-dnsop-dnssec-key-timing-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Dec 2014 03:21:14 -0000

Dear all,

I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last
call comments.

* Section 3.1:

Are all these states defined in this document. If not, please state
otherwise and provide a reference.


* Section 3.1, page 9:

> Dead        The key and is associated data are present in their
>             respective zones, but there is no longer information
>             anywhere that require their presence for use in
>             validation.  Hence they can be removed at any time.

It should say "and its associated..."


* Section 3.1, page 9:

> There is one additional state, used where [RFC5011] considerations
> are in effect (see Section 3.3.4):
> 
> Revoked     The DNSKEY is published for a period with the "revoke"
>             bit set as a way of notifying validating resolvers that
>             have configured it as an [RFC5011] trust anchor that it
>             is about to be removed from the zone.


Please phrase this one without an introduction. e.g.:

Revoked     The DNSKEY is published for a period with the "revoke"
            bit set as a way of notifying validating resolvers that
            have configured it as an [RFC5011] trust anchor that it
            is about to be removed from the zone. This state is used
            where [RFC5011] considerations are in effect (see
            Section 3.3.4)


* Section 3.2.2., page 13:

> At the end of this interval, key N is said to be dead.  This occurs
> at the dead time (Tdea) so:
> 
>           Tdea(N) = Tact(N+1) + Iret

Why not use this notation "Parameter(key_number)" for the figures? -- It
would make them way clearer.



* Section 3.3.5, page 23:
> In the case of an
> insecure parent, i.e. the initial creation of a new security apex, it
> is not possible to guarantee this.

Please define "security apex".

Happy holidays!


Thank you,
Tina