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

"Brian Weis (bew)" <bew@cisco.com> Fri, 06 January 2017 16:27 UTC

Return-Path: <bew@cisco.com>
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 89D041294C1; Fri, 6 Jan 2017 08:27:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.621
X-Spam-Level:
X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gGKf7kvUnkr8; Fri, 6 Jan 2017 08:27:04 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BB4129411; Fri, 6 Jan 2017 08:27:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16654; q=dns/txt; s=iport; t=1483720024; x=1484929624; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=918XoXiR27zK0SHl5py/kYIi5DVg4juiCo6tawzbI6U=; b=YuAA4T8SxAdDD6JI44KaHtw9ZwiiVGcuwVXJ0dn9nezDE1Ebd7reJ2wJ hqK4vIpMK71NJza8RI9k9v8Lb5sxUYKclaV15QqniphjRB01k/igM7QEZ JN66WG3Ffqna8hjPzCL22IHMRXsWHmhWGkBSjqPQodNXcCL1jOoeYh0Zd A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQCyxG9Y/5FdJa1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJxSAEBAQEBH4FrB41QkiGHf4d9hSqCCYYiAhqBOz8UAQIBAQE?= =?us-ascii?q?BAQEBYyiEaAEBAQMBI1YQAgEGAhEEAQEoAwICAh8RFAkIAgQOBYhVAxAIkmOdT?= =?us-ascii?q?oIlhzQNglYBAQEBAQEBAQEBAQEBAQEBAQEBAQEdiEcIgleCToFKEQEkDwoVEYJ?= =?us-ascii?q?BLYIxBZUahUM4AY1Kg3yQW4oDiE0BHzhtTxVEAYYUcwGGN4EhgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208,217";a="191193190"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2017 16:27:03 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v06GR3Gk006179 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 16:27:03 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 6 Jan 2017 11:27:02 -0500
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 6 Jan 2017 11:27:02 -0500
From: "Brian Weis (bew)" <bew@cisco.com>
To: Steve KENT <steve.kent@raytheon.com>
Thread-Topic: SecDir review of draft-ietf-sidr-adverse-actions-03
Thread-Index: AQHSZrFG45dF37AheEGMo+qlJtTspKErX+gAgACFhgCAABRrgA==
Date: Fri, 6 Jan 2017 16:27:02 +0000
Message-ID: <3971C5C5-1877-4205-88A4-CC1E2760AC1E@cisco.com>
References: <92CD5332-0DA4-4DD9-8973-17D0597A2696@cisco.com> <C5097058-B3E1-4F8F-BC9A-524AE692B03F@zdns.cn> <761fc144f6364e6c97a3bf9df2e3349a@CY1PR0601MB023.008f.mgd2.msft.net>
In-Reply-To: <761fc144f6364e6c97a3bf9df2e3349a@CY1PR0601MB023.008f.mgd2.msft.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.191.172]
Content-Type: multipart/alternative; boundary="_000_3971C5C51877420588A4CC1E2760AC1Eciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/vWYF7l9BY_jSPr1m8DbYVptdos4>
Cc: Chris Morrow <morrowc@ops-netman.net>, Declan Ma <madihello@icloud.com>, Stephen Kent <kent@bbn.com>, "db3546@att.com" <db3546@att.com>, secdir <secdir@ietf.org>, Declan Ma <madi@zdns.cn>, "akatlas@gmail.com" <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" <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 16:27:06 -0000

Hi Steve & Declan,

On Jan 6, 2017, at 7:13 AM, Steve KENT <steve.kent@raytheon.com<mailto:steve.kent@raytheon.com>> wrote:

Brian,

I agree that "addressed" should be changed. How about "encompassed”?

Perfect choice of word.


I agree that suppression also applies in the context of a planned  (or emergency) cert rollover. We can add a sentence to note that expiration of a cert that was intended to be rolled over is also a potential outcome.

That would be very useful, I think.

Thanks,
Brian


Thanks,

Steve
________________________________
From: Declan Ma <madi@zdns.cn<mailto:madi@zdns.cn>>
Sent: Friday, January 6, 2017 2:16:02 AM
To: Brian Weis (bew)
Cc: secdir; The IESG; draft-ietf-sidr-adverse-actions.all@tools.ietf.org<mailto:draft-ietf-sidr-adverse-actions.all@tools.ietf.org>; Stephen Kent; Declan Ma; Chris Morrow; Sandra Murphy; Alvaro Retana (aretana); db3546@att.com<mailto:db3546@att.com>; akatlas@gmail.com<mailto:akatlas@gmail.com>; draft-ietf-sidr-adverse-actions.all@ietf.org<mailto:draft-ietf-sidr-adverse-actions.all@ietf.org>; Declan Ma
Subject: Re: SecDir review of draft-ietf-sidr-adverse-actions-03

Dear Brian,

Thanks for reviewing this document.


> 在 2017年1月5日,01:37,Brian Weis (bew) <bew@cisco.com<mailto: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

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com<mailto:bew@cisco.com>