Subject: [Anima] Fwd: Re: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Mar 2019 08:38:46 +1300

It seems to me that BRSKI folk might have some comments on https://tools.ietf.org/html/draft-wkumari-opsawg-sdi

   Brian

-------- Forwarded Message --------
Subject: 	Re: [OPSAWG] "Secure Device Install" - draft-wkumari-opsawg-sdi
Date: 	Sat, 30 Mar 2019 10:16:18 +0100
From: 	Bill Fenner <[email-masked]>
To: 	Warren Kumari <[email-masked]>
CC: 	OPSAWG <[email-masked]>

Hi Warren,

The idea is interesting.  I definitely like the idea of having a lightweight mechanism for this - certainly customers have been asking for "secure no touch provisioning", whatever that means.  I'd like to throw out a couple of things for discussion:

1. Vendors (speaking as one) don't necessarily want it to be easy to find out what serial numbers we've built.  You may say "well change your serial number allocation", but, we have a whole logistics team that has way more input to that.  Also see https://en.wikipedia.org/wiki/German_tank_problem <https://en.wikipedia..org/wiki/German_tank_problem> .

2. If we create an identifier divorced from the serial number (e.g., a UUID) to avoid problem 1, we still need to provide that identifier to the customer somehow. The serial number is nice because it's written on the device, so you can tell which one you've got when you have a stack of 150 that you just received.  Perhaps there can be a service provided by the vendor that performs the dynamic mapping, but then that service is vulnerable to the dictionary attack to discover serial numbers (or needs to have countermeasures).

3. The vendor is now responsible for maintaining the public key until the user needs it.  Sure, storage is cheap, sure, I can back it up on Google Cloud, but that's still a new burden on the vendor (no matter how light weight it sounds).

  Bill