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

[Sean Turner <[e-mail]>]

> On Feb 13, 2019, at 20:10, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Tue, Feb 12, 2019 at 09:25:40PM -0500, Sean Turner wrote:
>> 
>> 
>>> On Jan 21, 2019, at 12:27, Benjamin Kaduk <[e-mail]> 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.

Thanks for the suggestions.  I’ll incorporate in the next version.

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

If it’s just missing a pointer to s8, maybe this would work:

See Section 8 for an additional workflow.

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

That I can get behind.  How about:

- Ensuring the cryptographic chain of custody from the manufacturer to operator.  For the pre-installed key material, the operator needs guarantees that either no one has access the private key or an authenticated log of those who have accessed it has been provided 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.)
>> 
>> 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.

Yep let’s remove it.

spt