[Sidrops] AD Review of draft-ietf-sidrops-rtr-keying

[Warren Kumari <[e-mail]>]

Thank you to the editors, SIDR and SIDROPS for your efforts on this
document, it's a well written and easy to understand draft. This document
is currently blocking the publication of
https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-rollover/ (for
344 days!), so I'm eager to get it out the door (and apologies for it
taking almost a month for my AD review!)

I do have a few editorial nits, and incorrect section numbers, that I’d
like addressed before I start IETF LC — addressing these now will help
avoid issues later in the process...[0]

Section 1:
-------------
1: "For example, when an operator wants to support hot-swappable routers
the same private key needs to be ..."
[O] to support hot-swappable routers the same private key
[P] to support hot-swappable routers, the same private key
[R] readability/grammar


2: "The remainder of this document describes how operators can use the
two methods to provision new and existing routers.  The methods
described involve the operator configuring the two end points (i.e.,
the management station and the router) and acting as the
intermediary.  Section 7 describes a method that requires more
capable routers."
[C]: I **think** that this is actually Section 8?


Section 5.2.  Operator-Generated Keys
---------------------------------------
3: That is the operator can verify the proof of possession
[O] That is the operator
[P] That is, the operator
[R] readability
(POP), as required by [RFC6484].

Section 7.  Install Certificate
------------------------------
4: To perform this verification the CA
[O] To perform this verification the CA
[P] To perform this verification, the CA
[R] grammar
certificate chain needs to be returned along with the router's
certificate in the PKCS#7 certs-only message.

Section 8.  Advanced Deployment Scenarios
----------------------------------------------
5: When a router is so configured the communication with the CA SHOULD
[O] When a router is so configured the communication
[P] When a router is so configured, the communication
[R] grammar
be automatically re-established by the router at future times to
renew or rekey the certificate automatically when necessary (See
Section 8).

NOTE: I believe that this is now Section 9...


Section 9.1.  Key Validity
--------------------------
6: Regardless of the technique used to track router certificate expiry
times, it is advisable to notify additional operators in the same
organization as the expiry time approaches thereby ensuring that the
[O] as the expiry time approaches thereby ensuring
[P] as the expiry time approaches, thereby ensuring
[R] grammar
forgetfulness of one operator does not affect the entire
organization.

Section 9.3.  Key Revocation
-------------------------------
7: Certain unfortunate circumstances may occur causing a need to revoke
[O] Certain unfortunate circumstances may occur causing a need to revoke a
router's BGPsec certificate.
[P] In certain circumstances, a router's BGPsec certificate may need to be
revoked.
[R] readability
a router's BGPsec certificate.

8: router's certificate, (possibly distributing a new key and
certificate to the router), and distributing the status takes time
[O] distributing the status takes time
[P] distributing the status, takes time
[R] readability. Or, better, could this be broken up into either a list or
two sentences?
during which the operator must decide how they wish to maintain


9: Keeping the router operational and BGPsec-speaking is the ideal goal,
but if operational practices do not allow this then reconfiguring the
[O] goal,
but if operational practices do not allow this
[P] goal; but, if operational practices do not allow this,
[R] grammar
router to disable BGPsec is likely preferred to bringing the router
offline.

10: and then make a next generation soon-to-be-
operational key, all hopefully without needing to take offline or
[O] key, all hopefully
[P] key. Hopefully, all this can be done
[R] readability
reboot the router.


Section 9.4.  Router Replacement
-------------------------------------
11: To allow operators to quickly replace routers without requiring
update and distribution of the corresponding public keys in the RPKI,
routers SHOULD allow the private BGPsec key to inserted via a
[O] to inserted
[P] to be inserted
protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP.


Section 10.  Security Considerations
------------------------------------
12: This document defines no protocols so in some sense introduces no new
[O] no protocols so in some sense
[P] no protocols. So, in some sense, it
[R] readability

security considerations.  However, it relies on many others and the
security considerations in the referenced documents should be
consulted; notably, those document listed in Section 1 should be
consulted first.

13:  PKI-relying protocols, of which BGPsec is one, have
many issues to consider so many in fact entire books have been
[O] to consider so many in fact entire books
[P] to consider - so many, in fact, that entire books
[R] readability/grammar

14: written to address them; so listing all PKI-related security
considerations is neither useful nor helpful; regardless, some boot-
[O] helpful; regardless,
[P] helpful. Regardless,
[R]
strapping-related issues are listed here that are worth repeating:


15: Public-Private key pair generation:  Mistakes here are for all
practical purposes catastrophic because PKIs rely on the pairing
[O] Mistakes here are for all practical purposes
[P] Mistakes here are, for all practical purposes,
[R] readability/grammar
of a difficult to generate public-private key pair with a signer;
all key pairs MUST be generated from a good source of non-
deterministic random input [RFC4086].

16: Private key protection at rest:  Mistakes here are for all practical
purposes catastrophic because disclosure of the private key allows
[P] same as prior comment
another entity to masquerade as (i.e., impersonate) the signer;

17: Private key protection in transit:  Mistakes here are for all
practical purposes catastrophic because disclosure of the private
[P] same as two prior.
key allows another entity to masquerade as (i.e., impersonate) the
signer;

-------------------------------------------

Please let me know LOUDLY once you've had a chance to look at these, and
I'll kick of IETF LC.

W
[0]: Once people start pointing out nits, they seem to continue (and yes, I
get the irony :-))



--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf