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

From: Ben Campbell <[email-masked]>
Date: Tue, 22 Jan 2019 19:26:22 -0800

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:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 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?

§10:

- "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?

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Jan 2019 20:31:41 -0800

on the issue of uploading private keys.  how the wg got where we are.
essentially, we made the mistake of letting operators in.

it's 2am.  the bleeping device melted.  a new key generated by a
replacement device will take a good while to get into the rpki and then
many more hours to get into everybody's bgpsec validation key caches
around the planet [ask geoff why he insisted he did not have to publish
more frequently than once a day].  and by 3am, people with shiny shoes
will be giving the op snake eyes that customers in tiblisi can't give
them money online right now.  when the op tells them it will be tomorrow
afternoon, it is usually referred to as a resume generating event.

randy