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

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.