Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Aug 15, 2019 at 01:02:45PM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <[e-mail]> wrote:
>     >> There does not otherwise seem to be any risk from this compromise to
>     >> devices which are already deployed, or which are sitting locally in
>     >> boxes waiting for deployment (local spares).  The issue is that
> 
>     > (That is, if the boxes are already in local storage at the time of
>     > first compromise)
> 
> yes. If you have physical care of them, then nobody could have tried an
> attack while the MASA signing key was compromised.

I guess that makes the "under physical control of the owner" the relevant
property, so emphasizing that in the text might be good.

>     >> The authors are unable to come up with an attack scenario where a
>     >> compromised voucher signature enables an attacker to introduce a
>     >> compromised pledge into an existing operator's network.  This is the
>     >> case because the operator controls the communication between Registrar
>     >> and MASA, and there is no opportunity to introduce the fake voucher
>     >> through that conduit.
> 
>     > This seems predicated on the attacker having the MASA signing key but
>     > not persistent control of the (formerly?) legitimate MASA service,
>     > right?
> 
> yes, that's right.  Assume the key was generated in a deterministic way
> (the way the SSH keys were), or brute-forced, or something like that.

I was initiall confused about this, so it might be worth adding some text.
(But then again, sometimes I'm easily confused...)

>     >> A key operational recommendation is for manufacturers to sign
>     >> nonceless, long-lived vouchers with a different key that they sign
>     >> short-lived vouchers.  That key needs significantly better protection.
>     >> If both keys come from a common trust-anchor (the manufacturer's CA),
>     >> then a compromise of the manufacturer's CA would be a bigger problem.
> 
>     > (probably some wordsmithing options for "be a bigger problem")
> 
> how about:
>               If both keys come from a common trust-anchor
>               (the manufacturer's CA), then a compromise of the
>               manufacturer's CA would compromise both keys.  Such a
>               compromise of the manufacturer's CA likely compromises
>               all keys outlined in this section.

WFM.

Thanks,

Ben