Re: [secdir] sector review of draft-ietf-sidrops-rtr-keying-02

[Sean Turner <[e-mail]>]

Daniel,

Hi and thanks for the review!  My comments are prefaced with [spt].

----------

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.

[spt] So, you got me.  I totally agree that we do not want to be advocating manually copying around the private keys.  It is just bad practice and fraught with problems.  But, this is is the process I’ve been told some implementations need to follow to get them to work.  Until we actually get better tooling and something that looks more like what’s described in s8 (Advanced Deployment Scenarios) I am afraid that we’re probably stuck with the operator-driven model.


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.


[spt] the RTGDIR and OPSDIR had the same comment.  In the RTGDIR response, we agreed to have the IESG just tell us what it ought to be, but it looks like now we’re going to BCP now that all of the reviews have questions the intended status.  Here’s what I said in response to the OPSDIR review:

[spt] I seem to remember a discussion about whether this should be BCP or ST.  We discussed BCP addressing both what the IETF wanted to be the best practice as well as what is the actual current practice.  Since BGPsec was/is new it was hard to say it fell in the latter bucket and there was at least one person who felt that the router and operator driven methods weren’t te way to go in the future (hence why there is s8 the "advanced deployment scenarios” section).  So the WG said go ST and because this draft has exhausted me we just changed it to ST.  I will note that the SECDIR and RTGDIR both had this same comment it seems like we’re back to BCP.  I think there was another message somewhere about changing this to BCP so I will do that in -03 unless I hear otherwise.


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.

[spt] The RTG Directorate wondered the same thing so I changed it to: There are two methods, router-driven and operator-driven.


> 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.” 

[spt] Fully agree will incorporate in -03.


> 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”.

[spt] Agreed will be incorporated in -03.


> 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”.

[spt] Agreed will be incorporated in -03.


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

[spt] Agreed will be incorporated in -03.


> 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”.

[spt] RTG Directorate noticed this too and it was changed in -02.


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

Inappropriate comma.

[spt] Agreed will be incorporated in -03.


> The operator burden shifts here to include:

Should be "operator's burden”.

[spt] Agreed will be incorporated in -03.


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

Hyphenate "BGPsec-speaking”.

[spt] Agreed will be incorporated in -03.


> Ensuring this is not terribly difficult but requires that either The subsequent "has", "notes", "warns", "uses" should be the subjunctive "have", "note", "warn", "use”.

[spt] Agreed will be incorporated in -03.


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

[spt] thanks to you and Danny!