Last Call Review of draft-ietf-sidrops-rtr-keying-01
review-ietf-sidrops-rtr-keying-01-secdir-lc-franke-2018-12-11-00

Request Review of draft-ietf-sidrops-rtr-keying
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-12-18
Requested 2018-12-04
Authors Randy Bush, Sean Turner, Keyur Patel
Draft last updated 2019-01-23
Completed reviews Rtgdir Last Call review of -01 by Dhruv Dhody (diff)
Secdir Last Call review of -01 by Daniel Franke (diff)
Opsdir Last Call review of -02 by Scott Bradner (diff)
Assignment Reviewer Daniel Franke 
State Completed Snapshot
Review review-ietf-sidrops-rtr-keying-01-secdir-lc-franke-2018-12-11
Reviewed rev. 01 (document currently at 06)
Review result Has Issues
Review completed: 2019-01-23

Review
review-ietf-sidrops-rtr-keying-01-secdir-lc-franke-2018-12-11

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.

The summary of the review is Ready with Issues.

This document is well-written and generally sensible. I have just one major substantive concern, which is with this remark:

"[W]hen an operator wants to support hot-swappable routers, the same private key needs to be installed in the soon-to-be online router that was used by the the soon-to-be offline router. This motivated the operator-driven model."

This justification doesn't make sense to me. Surely it's possible for the two routers to have two different, concurrently-valid certificates, with the same Subject Name but different keys, each of them generated on the respective device? It must be, because this is explicitly described in the case of certificate rollover, and the two cases oughtn't look any different from the outside other than the "staging period" being much-prolonged.

I'm not going to advocate for complete elimination of the operator-generated method, but only because I know people are going to do it no matter what we tell them, whether it's a good idea or not. But we shouldn't be rationalizing copying private key material around when it isn't really necessary to do so.

Moving to meta-level concerns, this document reads much more like a BCP than a Proposed Standard. I note that it actually started that way, but was changed in November 2015. I can't find any record in the mailing list archives or meeting minutes of what motivated the change. I can venture a guess that at the time, the authors didn't feel that the "current" part of "best current practice" was truthful advertising. But if that's the case then this seems like a good time to reconsider in the light of the past three years of RPKI and BGPsec adoption.

This document contains 18 instance of SHOULD/RECOMMENDED and just two instances of MUST, and one of those two is a requirement on the behavior of the operator(!). I find this ratio troubling for a standards-track document and think it may be a symptom of inappropriate classification.

Editorial nits:

> There are two sub-methods, router-driven and operator-driven. These two sub-methods differ…

Why are these called "sub-methods" here when in the rest of the document they're just "methods"? In various other places the document also uses "model" in place of "method" with no clear distinction.

> Though other configuration mechanisms might be used, e.g.  NetConf (see [RFC6470]); for simplicity, in this document, the protected channel between the management platform and the router is assumed to be an SSH-protected CLI.

The semicolon is ungrammatical. The sentence might scan better as "Though other configuration mechanisms might be used, e.g.  NetConf [RFC6470], the protected channel between the management platform and the router is assumed in this document to be an SSH-protected CLI."

> A number of options exist for the operator management station to exchange PKI-related information with routers and with the RPKI including …

The subsequent occurrences of "use" should be "using" or "to use" in order to complement the subject "a number of options".

> Once generated, the PKCS#10 certification request is returned to the operator over the protected channel.

Unnecessary passive voice. Rewrite as "Once the router has generated the PKCS #10 certification request, it returns it to the operator over the protected channel".

> Beware that experience has shown that copy and paste from a management station to a router can be unreliable for long texts.

"copy-and-paste" should be hyphenated.

> The router SHOULD extract the certificate from the PKCS#7 certs-ony message and verify that the public key corresponds to the stored private key

Typo: "certs-ony".

> Signing the PKCS#8, permits more advanced configurations where the entity that generates the keys is not the direct CA.

Inappropriate comma.

> The operator burden shifts here to include:

Should be "operator's burden".

> It is critical that a BGPsec speaking router is signing with a valid private key at all times.

Hyphenate "BGPsec-speaking".

> Ensuring this is not terribly difficult but requires that either

The subsequent "has", "notes", "warns", "uses" should be the subjunctive "have", "note", "warn", "use".


Thank you Danny Cooper, who knows much more than I do about RPKI, for sanity-checking my thoughts.