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

Benjamin Kaduk <kaduk@mit.edu> Mon, 21 January 2019 17:27 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27234124D68; Mon, 21 Jan 2019 09:27:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com>
Date: Mon, 21 Jan 2019 09:27:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/8gW1UGzDj_RRHsqmcGJBodVdeTY>
Subject: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jan 2019 17:27:53 -0000

Benjamin Kaduk 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:
----------------------------------------------------------------------

I know the intended status has been beaten to near death already, but I
could see this as Informational as well as BCP.

Section 1

                                      For example, when 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
   method

As the secdir review notes, there is no need to copy private keys to hot-swap routers
(unless there is something special about the "hot-swap" case that nullifies
the arguments he made?).

It rather seems that we should avoid framing this behavior as justified by
a need for hot-swapping, but rather as something that people do to work
around processes that do not admit the more secure workflow, as an
operational reality.

Section 2

   (see [RFC6470]), the protected the protected channel between the

nit: duplicate "the protected"

Section 5

   The PKCS#10 request SHOULD be saved to enable verifying that the
   returned public key in the certificate corresponds to the private
   used to generate the signature on the CSR.

I mostly assume this is done by the party that generates the CSR, though
perhaps one could read it as being done on the router always.  (I guess
later on we do recommend both the operator and router to do this
verification.) This could be reworded, though, either to remove the 2119
language ("Retaining the CSR allows for verifying that [...]" or to apply
to the actual verification as opposed to just the saving.

Section 5.1

   NOTE: If a router were to communicate directly with a CA to have the
   CA certify the PKCS#10 certification request, there would be no way
   for the CA to authenticate the router.  As the operator knows the
   authenticity of the router, the operator mediates the communication
   with the CA.

nit: I think that the thing we care about here is the CA's ability to show
that the request is authorized.  The operator is assumed to have an
account/relationship with the CA and a channel via which to authorize
cert-signing requests.  In particular, "no way" is a rather strong
statement, and would seem to deny the possibility of a three-party workflow
where the router sends the CSR to the CA but the operator logs in to the CA
independently and is presented with a list of pending requests to approve.
(It would also preclude the operator from delegating their authorization at
the CA to the router, as described in Section 8.)

Section 5.2 ("Operator-Generated Keys")

   Even if the operator cannot extract the private key from the router,
   this signature still provides a linkage between a private key and a
   router.  That is, the operator can verify the proof of possession
   (POP), as required by [RFC6484].

This paragraph seems a bit of a non-sequitur -- if the operator just
generated the key, it sure isn't going to need to extract the private key
from the router to sign something using it!

Section 6

   In the operator-generated method, the operator SHOULD extract the
   certificate from the PKCS#7 certs-only message, and verify that the
   private key it holds corresponds to the returned public key.  If the

nit: "private key it holds" is the one the operator holds, not the PKCS#7
certs-only message.  It's probably worth disambiguating, here.

Section 7

   NOTE: The signature on the PKCS#8 and Certificate need not be made by
   the same entity.  Signing the PKCS#8 permits more advanced
   configurations where the entity that generates the keys is not the
   direct CA.

Why are we talking about PKCS#8 (asymmetric key transport) signatures here
at all?  This is the section about installing certificates!  I guess I am
not terribly familiar with the RPKI, but in the Web PKI at least it's quite
uncommon for the CA to be generating the private keys, so mentioning these
together is a non sequitur to me.

Section 8

   More PKI-capable routers can take advantage of this increased
   functionality and lighten the operator's burden.  Typically, these

nit: most readers will not bind "this" to the right thing and will instead
be left confused.

Why do we not mention the need to get the manufacturer-installed key
material (or information thereof) to the operator?

   When a router is so configured, the communication with the CA SHOULD
   be automatically re-established by the router at future times to
   renew or rekey the certificate automatically when necessary (See
   Section 9). This further reduces the tasks required of the operator.

Mentioning renewing certificates is natural, as they have a stated end time
to prepare for.  Re-keying certificates is something of a different matter,
and it would be nice to provide (a link to) some guidance on what
timescales at which to rekey, if we're mentioning rekeying here.
(draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I
did not see much concrete on this point.)

Section 9.4

   Currently routers often generate private keys for uses such as SSH,
   and the private keys may not be seen or off-loaded from the router.
   While this is good security, it creates difficulties when a routing
   engine or whole router must be replaced in the field and all software
   which accesses the router must be updated with the new keys.  Also,

This seems to be talking about key management for keys other than
BGPsec-signing keys.  Isn't that out of scope for this document?

   any network based initial contact with a new routing engine requires
   trust in the public key presented on first contact.

   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 be inserted via a

Making this a SHOULD is perhaps an overstatement, since AFAICT this
functionality is not useful for the stated purpose unless the operator has
access to private keys directly (whether by virtue of the operator having
generated the keys or an extraction interface on the current routers).
This is an inherent tradeoff, as stated, between the delay in
update/distribution of public keys in the RPKI vs. reducing the risk of
unauthorized key access.  I'm not making this a Discuss point because it's
not exactly my tradeoff to make, but I do want to be sure that this is
actually the tradeoff that SIDROPS wants to present to the community.

   protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP.  This
   lets the operator escrow the old private key via the mechanism used
   for operator-generated keys, see Section 5.2, such that it can be re-
   inserted into a replacement router. The router MAY allow the private
   key to be to be off-loaded via the protected channel, but this SHOULD
   be paired with functionality that sets the key into a permanent non-
   exportable state to ensure that it is not off-loaded at a future time
   by unauthorized operations.

This last sentence is a somewhat different topic and could probably stand
alone as its own paragraph.  This would also provde the opportunity to
clarify that this offload interface is intended for use in conjunction with
key generation, and the permanent non-exportable state to be applied
thereafter.

Appendix A

I agree with Mirja about the duplication of content and thus non-need for
normative language.