[Sidrops] Ben Campbell's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 23 January 2019 03:26 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833B9130E0E; Tue, 22 Jan 2019 19:26:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.90.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154821398252.13239.9780042427198357683.idtracker@ietfa.amsl.com>
Date: Tue, 22 Jan 2019 19:26:22 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1OGdHtWF4s59ZOAElNvP50M3gZc>
Subject: [Sidrops] Ben Campbell's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2019 03:26:23 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-sidrops-rtr-keying-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


- General: The document says it's intended as BCP, but the data tracker says
"Proposed Standard". Was this last called with the correct status?  (I agree
with BCP, by the way.)

- I share Benjamin's concern about the idea of moving private keys between
routers as a "need" vs "something people do".

§5.2.1: "The router should inform the operator
whether or not the signature validates to a trust anchor; this
notification mechanism is out of scope."

Should that be normative?

§9.3: The second paragraph is a single convoluted sentence. Can it be broken
into simpler sentences?


- "This document defines no protocols. So, in some sense, it introduces
no new security considerations."

I think practices can absolutely come with security considerations. For
example, the practice of moving private keys between routers.

- "Private key protection in transit": Is there no expectations that
transmitted private keys would have object-level encryption?

§A: I'm curious why this is not part of the main-body security considerations?