Re: [secdir] SecDir review of draft-ietf-sidr-adverse-actions-03

Declan Ma <madi@zdns.cn> Fri, 06 January 2017 07:18 UTC

Return-Path: <madi@zdns.cn>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B17129C44 for <secdir@ietfa.amsl.com>; Thu, 5 Jan 2017 23:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 dp00FIxz0JNt for <secdir@ietfa.amsl.com>; Thu, 5 Jan 2017 23:18:17 -0800 (PST)
Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE59129C42 for <secdir@ietf.org>; Thu, 5 Jan 2017 23:18:17 -0800 (PST)
X-TM-DID: 9f06655e8208d580e0bc5702617c76e2
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Declan Ma <madi@zdns.cn>
In-Reply-To: <92CD5332-0DA4-4DD9-8973-17D0597A2696@cisco.com>
Date: Fri, 06 Jan 2017 15:16:02 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5097058-B3E1-4F8F-BC9A-524AE692B03F@zdns.cn>
References: <92CD5332-0DA4-4DD9-8973-17D0597A2696@cisco.com>
To: "Brian Weis (bew)" <bew@cisco.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/D6QTdsAJHVscGDiV2Bk_oDm77b8>
Cc: Chris Morrow <morrowc@ops-netman.net>, Declan Ma <madihello@icloud.com>, Stephen Kent <kent@bbn.com>, db3546@att.com, secdir <secdir@ietf.org>, Declan Ma <madi@zdns.cn>, akatlas@gmail.com, "draft-ietf-sidr-adverse-actions.all@tools.ietf.org" <draft-ietf-sidr-adverse-actions.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>, draft-ietf-sidr-adverse-actions.all@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-sidr-adverse-actions-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 06 Jan 2017 07:18:18 -0000

Dear Brian,

Thanks for reviewing this document.


> 在 2017年1月5日,01:37,Brian Weis (bew) <bew@cisco.com> 写道:
> 
> 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 primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
> 
> As stated in the Abstract, this document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. Put another way, it documents threats to the RPKI/BGPSEC PKI, in which there are unique threats to the PKI that can adversely affect Internet routing. The document is well written and internally consistent. The Security Considerations section is adequate.
> 
> I consider this draft Ready to publish, but here are a couple of discretionary comments for the authors.
> 
> 1. The end of section 2 says "Note that not all adverse actions may be addressed by this taxonomy.”. The phrase “addressed by” confused me a little bit, as it implies some recommendation or remediation — which this document does not attempt to do. This might be more clearly worded as “described by” or “included in”.

I think this is really a good suggestion. 

> 
> 2. In section 2.1, A-1.2 (Suppression), it seems that suppression could result in the CA certificate intended to be replaced to expire before an intended CA rollover operation happens due to thes suppressed replacement certificate. Perhaps it is not noted because this threat is not specific to RPKI/BGPSEC, but it could be another serious suppression affecting Internet routing. 

CA rollover operation is a specific scenario where CA certificate suppression could take place. As this document focuses on the harmful results of adverse actions not the causes nor motivations of adverse actions, we authors don’t note this case specially you just mentioned.  Anyway, we authors will be considering this comments from you when updating this draft in its next version.

Di