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

Benjamin Kaduk <kaduk@mit.edu> Thu, 14 February 2019 01:10 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE29129AA0; Wed, 13 Feb 2019 17:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq7Dz3A9QLZf; Wed, 13 Feb 2019 17:10:38 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780104.outbound.protection.outlook.com [40.107.78.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2654A130DE3; Wed, 13 Feb 2019 17:10:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FzSg08X+GwThpmO6r16Utf/nNiJ+uhGCMzOBpnkfuNk=; b=FAWglT24+Fhpqnqp6jmOJzLWR4DuWq8gpT+xm7VEnXprQNEOBiHCJ1KNsz14ahgEBxLh45O+lt5GUgLMGtD8RMxDtDen0sqCA/qYY5jcssniCU/rqx+b/sDL2/uvWWmrmtncm3w5PgcJIaeF+T7TbUfwrB5a0q+1OxBasfVCqfY=
Received: from BYAPR01CA0020.prod.exchangelabs.com (2603:10b6:a02:80::33) by SN6PR01MB3757.prod.exchangelabs.com (2603:10b6:805:17::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 01:10:36 +0000
Received: from CO1NAM03FT012.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::207) by BYAPR01CA0020.outlook.office365.com (2603:10b6:a02:80::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Thu, 14 Feb 2019 01:10:35 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT012.mail.protection.outlook.com (10.152.80.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Thu, 14 Feb 2019 01:10:35 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1E1ATUq020717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 20:10:31 -0500
Date: Wed, 13 Feb 2019 19:10:29 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sean Turner <sean@sn3rd.com>
CC: <draft-ietf-sidrops-rtr-keying@ietf.org>, The IESG <iesg@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, SIDROps Chairs <sidrops-chairs@ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20190214011028.GF56447@kduck.mit.edu>
References: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(136003)(2980300002)(51444003)(199004)(189003)(478600001)(305945005)(55016002)(76176011)(229853002)(8676002)(246002)(104016004)(8936002)(86362001)(26826003)(316002)(58126008)(36906005)(786003)(106002)(54906003)(75432002)(23676004)(2486003)(7696005)(26005)(2870700001)(186003)(106466001)(336012)(6916009)(14444005)(126002)(50466002)(426003)(11346002)(2906002)(446003)(53416004)(6246003)(476003)(30864003)(956004)(4326008)(486006)(66574012)(53546011)(1076003)(561944003)(47776003)(356004)(33656002)(88552002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB3757; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1;
X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT012; 1:u00Mwp0MQoX/LM7/qENl487umlVWT3u+kE9Qnrch00zSD1ZkQ6fYeNDC1JACpjyjtvCCZ3G1wvCVa3G8O22awirjFfDVdua+6qzRXfGMwZUTH0bFRlPOQwg4AvygcaoVMudRqTxENDqOUD2SU+W8I6rJ90rlkeiw0xZhVBQlDxU=
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c899ae8a-9a5c-4fe7-e0d8-08d692193988
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB3757;
X-MS-TrafficTypeDiagnostic: SN6PR01MB3757:
X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3757; 20:Kardiz5ylOkAZT/BC2x0KUg7AZhCD01CrIc4Th7WwTZV6BYEg3h0DUUpOoFDi71vpGo/QyS2xHEZr+hlfGPwcXnrChpQTFm3yilE99cKHZm180vkwal26lQYqiiq5UhnFcoQ7zBee7BHOLoUJ/DXnvh6cFNPnmwPqsEdvgLoaQU1Zz8fa1NsOyMfEbCc5Z1FUyJlmd+SlAKjEPIvs3Yqg9cIgPAeit4AIhDHS6vCEUbjqSdW5kaySxnE9qBRyCxjM9Qavgvm6Axb1HJ3OfTp/7OVONyzIC8KJJhWzrqq7UhqBVMLhLqBnoAoutY4cASXGIcDm8XBVlvxFkJmhEzHQBd7yjUlojCCw1QLUi/Kyw+n55EPBqTI6h/0oJSYSnuPTBZbling5sUSxf7lZHcif8ut7nFZs1QuKTsJI8tFrnZp4wOhomWAK4CAxUWq1/GIppA0Ir5dqpdsn6MWTF0dt3XrJjhXP9LfAHIr1M5C/ckO/+EG5+NwqvAFaoXSBdxcl077taMMmgak3qtZlDX0VPMkw2IxCsOSCYhba+x2za4J2dGjtXrJ7BG2utnbj6bEca3kBJphOAQRRYr18hBpfV0gIX4dY1+1gr0uiHOCj2Y=
X-Microsoft-Antispam-PRVS: <SN6PR01MB3757F0B3BEF2314F02A57819A0670@SN6PR01MB3757.prod.exchangelabs.com>
X-Forefront-PRVS: 09480768F8
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjZQUjAxTUIzNzU3OzIzOnFCQ0U5d0N1NVlTYnF2ZjZNR1RteXl2dWtr?= =?utf-8?B?b085Um0xOW01TFF1U2k3THpIcys3eXdrTk10NGVpdUlpVXAyekJzRjhCb2lv?= =?utf-8?B?dytVdmlzaGtQL05GV1JJQUFKOXRNZ3kvazAzTkkwZHpRYzlVYTlBTnVqQnhR?= =?utf-8?B?VWkzV3FaSnNTZ0d4SmtXbVFzNjNMUHlaRzNvY3FTNzcraVUvT3pTZzJVcmNB?= =?utf-8?B?ejRkRWg2bEJ2a0FlOVFzNTlRYnZ1bGorQzBITmlCRTZjLy8wWTh6V05XSkk5?= =?utf-8?B?UDYvM0F6ODg0V1ZmYUVVTHh3NEp5OG9rVWhUWmhhdGtGTVkxVlhSbmt2djBn?= =?utf-8?B?eityVEhxejdTMFEwQXAvYzgxaGY0WW9hTXFodk0xOStqU0szLzROM3o5NmJ2?= =?utf-8?B?em1LMWQrazN6cUMrSHFkWEpVMEtDbzRFUTNTR0RaU0hneE5hRkphT1pXOER5?= =?utf-8?B?WEMwWEZiMXVSZlUyckFCc2JWazZ6Ti9UN0UzUzJrSCtldzFvRjk5SUE2ejVa?= =?utf-8?B?M3o3WDJFeVhmRk5oM1gyRmRpdjh1UC9MMzdpS1RsOUJIaE9jZVhURXd0ZVpv?= =?utf-8?B?NHpubGNhQUF0S1FXTW0yY3B5dXo2eTJkY2VxZHRJU3pyUTVsU0MrbVFRUHRY?= =?utf-8?B?SmpOcnJrU3RJdGpzSEJ3ZGN2MndvT2phSWROR0pVVmhhQ2QyQmJ5M2cxZWNx?= =?utf-8?B?dTI0eDE2aE1LaGtPUC9DcTdkR2ppajhRSnpFR2FqNWcyd0tSckhkVGk3a0ha?= =?utf-8?B?aUprbUp1YmJpTmltVTVQeDRxSFlvWlZWL2tBQlFBNVJsaTdhWGJsTHN5M2hU?= =?utf-8?B?MEZwbVZhd1FTcW1KWiszdlZsTEdYL0twcjFkV2VZRWxJblZmZmVhMjhaODE0?= =?utf-8?B?aXg5Tzd6NWxaWnQ2TC9UNk1lNXVpUlBrUTBRazFNOHJmQlBvcVdWaWl1S3gw?= =?utf-8?B?OWM2alVGanlsTnhQbEd6bkY3TEU0REpJV21VRXlhb2I4bXNkTGMzWXNUK0Mz?= =?utf-8?B?WU9sbnFKNnNvVEdkZFJ2L1dBZVdyaEN0Mm14S1hjYU1zL3FGZDBZbWU0cmR5?= =?utf-8?B?M0VhbUVHVmZ3NzU2NjV0VHpkK256cjNNOFlHWDN1RDZCRzh1cGtVOEVWQ3pU?= =?utf-8?B?aE4veGRrcFJzaTlZRUlXQ08yaWQ5SEVwaTl1OHRUZnJmaTRDcXMrYnF2bmMx?= =?utf-8?B?TFZtMCs4MUtLUUNmVTBoVnhyT3gvQkZlK0pVeTVnRG52eC9KSUdmNWtjZ2lH?= =?utf-8?B?WUxqVkNzakR5L1Brbncvb0QzQlpUeU5RMWlnVW1HQmJKSFppQmhGWUYxcG5l?= =?utf-8?B?bGJDZ1AzeHQyQmMyZ2Zvc0JaV1dtTEo4bTN4RHpCc3FWMDR4akZOaHUwM2xt?= =?utf-8?B?MDhiYUlKV2oxTW9zNTQ3U2pFaHpLR2VxMmpTOUNkUmFFNmFjUDVpQ0J1SWtV?= =?utf-8?B?NEZQZnY2a2FtV0E1V28rM0s4ZXc5NW56bUFPeklkejZTVWFKTXdPWERrZERU?= =?utf-8?B?cTRGS1NMdkVINTB6T0ZLc1ZYcDFpc2hyNnlaWkE0M1NWRmhPMm8wM3BQQ3F2?= =?utf-8?B?QWNua2lqUU1nQlpNc1NTYVRkZGsxdmh2RG9OWlhPSXZXckVPcnh4YVU5ZGRt?= =?utf-8?B?UStxR1pRZkpCaUNXV3diQ3pkdmlXRGQvZmpHR1BTSEZxeFE2ZFlvaEdLRGV6?= =?utf-8?B?eFlwRGZnMXhCb2VGSFNsaDVvUEhnWTlPTERDU0VheDlOVDk3bVFTNndsbG9h?= =?utf-8?B?NS9ZWU9ZdGFpU1RzaEVGZz09?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: C8E8NhWhcspumSbZ2UtMxA8g/PPzEuhCTHMUUDwWZKCZ0VDm8+BQ+LRstWeUpsKTsPKDy3OPIlNK8CTCm7mimaj7V7Kou1K5vlcsak4d35qOptVkkweIk18+Qr6hz0GaGcbPaaYDFslpisxyPhvMZdp9o4lTyfXUbJXAUUH0EOc1Rm2HsLYrYIj/l0I7JJ57QMopNCK2OuLjBNWiC5s1KtJa7rW0I7QTlY0KaHV49jhhBdvXFD5U82b7Cw+yksybLYByGA8QrQy4qtvLSJKOQvxnx6C53M2LdMKCrg5fbo57z49VEXoiP7kB79PPsI1vrqMahMdORA/4BLBvZa0gwzrrP+5soRqTWdcqB8c5kpxF1TNVldxVahtfly/MXFVr129pvqd39otsAVQFV8HLYeR+TROAFA8TaoB0C04qmH8=
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2019 01:10:35.1511 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: c899ae8a-9a5c-4fe7-e0d8-08d692193988
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB3757
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/2PIlxiUTHQ9DexzzKAjw_HZF_3Y>
Subject: Re: [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
Precedence: list
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: Thu, 14 Feb 2019 01:10:51 -0000

On Tue, Feb 12, 2019 at 09:25:40PM -0500, Sean Turner wrote:
> 
> 
> > On Jan 21, 2019, at 12:27, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> > 
> > 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.
> 
> Would something like the following work:
> 
>    The operator-driven model is motivated by ensuring the network operates.

"motivated by the extreme importance placed on ensuring the continued
operation of the network"?

>    In some deployments, 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 (i.e., operators need to support hot-swappable
>    routers.

Per Randy's suggestion, I might drop the parenthetical and go with
"soon-to-be-offline router, since this "hot-swapping" behavior can result
in minimal downtime, especially compared with the normal RPKI procedures to
propagate a new key, which can take a day or longer to converge".

> 
> BTW - I am totally open to wording suggestions.
> 
> 
> > Section 2
> > 
> >   (see [RFC6470]), the protected the protected channel between the
> > 
> > nit: duplicate "the protected”
> 
> fixed
> 
> > 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.
> 
> I am all about dropping 2119-lang where we can so will reword as suggested:
> 
>    Retaining the CSR allows for verifying that the
>    returned public key in the certificate corresponds to the private
>    used to generate the signature on the CSR.

SGTM

> > 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.
> 
> Yes
> 
> >  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.)
> 
> Okay fair point.  Maybe we reword it to say:
> 
>   NOTE: The CA needs to now that the router-generated CSR is authorized.
>   The easiest way to accomplish this for the operator to mediate the
>   communication with the CA.  Other workflows are possible, e.g.,
>   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.
> 
> Again, totally open to word smithing.

No changes to your proposal are immediately jumping out at me, though I do
wonder if a xref to section 8 is worth attempting.  (AFAICT it would
require additional wordsmithing, though, which we may lack motivation to
pursue.)

> > 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!
> 
> Yeah if they just made it they certainly have access to it.  The concern was really more about router-driven models where there’s now way to get the private out so this paragraph ought to move to s5.1.
> 
> > 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.
> 
> I think you are suggesting the following:
> r/private key it holds corresponds to the returned public key/
> private key the operator holds corresponds to the returned public key in the PKCS#7 certs-only message.

I think so, too :)

> > 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.
> 
> In the WebPKI it’s really uncommon, but it is done in lots of other places, e.g., little devices with no human interface.  Some entity creates the keys enmass, farms ‘em out when requested, and these farmed keys are verified to make sure they come from the trusted key generation source.
> 
> But more to the point, the note is there because we do discuss PKCS#8 in s5.2.1 and it seemed like a good place to say hey - don’t assume the signatures are from the same place.  In most cases they will be but not necessarily.

Okay.

> > 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.
> 
> I am thinking I could just strike the ”this”.
> 
> > Why do we not mention the need to get the manufacturer-installed key
> > material (or information thereof) to the operator?
> 
> But, I thought that’s what the entire 1st paragraph is about?

Looking back, this comment is pretty opaque and even I myself am only 90%
sure I figured out what I was trying to say.  Sorry about that!

I think I wanted to have another enumerated item as the "operator's
burden", for ensuring the cryptographic chain of custody from manufacturer
to operator (for the pre-installed key material, or handles thereto).

> >   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.)
> 
> We’d end up in a circular reference point then since they point to our document.  The thing here is that the lifetimes of the keys are entirely dictated by the PKI CPs and there’s more than one place to point.  Not sure I have good fix for this one.
> 
> Randy/Keyur?

Given Randy's comment, maybe we could just remove the mention of "or
rekey"?  I'm not sure.

> > 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?
> 
> On the one hand yes, but on the other hand no.  Because this section is about overall router security we felt it ought to be included and I do not think that it hurts to keep it.  And, like people screw this up regularly.
> 
> >   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.
> 
> It’s definitely been in the draft for a while now.  I guess folks can speak up if they think it’s wrong.
> 
> Randy/Keyur?
> 
> >   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.
> 
> How about:
> 
>    The router MAY allow the private key to be to be off-loaded via the
>    protected channel after key generation, but this SHOULD be paired
>    with functionality that sets the newly generated key into a permanent non-
>    exportable state to ensure that it is not off-loaded at a future time
>    by unauthorized operations.

That's an improvement, thanks.

-Benjamin

> > Appendix A
> > 
> > I agree with Mirja about the duplication of content and thus non-need for
> > normative language.
> 
> Agreed. I removed the 2119-language from Appendix A.
> 
> spt