Re: [Netconf] send 'version' in zerotouch url?

[Kent Watsen <[e-mail]>]

[Note: this issue is blocking the posting of an updated zerotouch draft, which would then be ready for a (presumably) final Last Call]

Second try  ;)

The issue regards when a device learns of a bootstrap server's address/port via an insecure mechanism (e.g., DHCP or a DNS record).  As such, the device will not have a trust-anchor certificate to authenticate the bootstrap server's TLS certificate with.  For such cases, the draft allows the device to establish the TLS connection with the bootstrap server anyways (e.g., by blindly accepting the server's certificate).  However, the concern is that the bootstrap server may "owned" by an attacker...

To safeguard against this scenario, the draft (1) says that the device MUST verify (via a signature) any data it obtains from the [untrusted] bootstrap server and (2) takes steps to limit the amount of data the device sends to the [untrusted] bootstrap server.  

Currently, the draft has robust support for goal #1 and partial support for goal #2.  For goal #1, the draft defines a signed-data solution (owner certificates, ownership vouchers, etc.).  For goal #2, the draft prevents the device from sending its IDevID certificate or POST-ing its 'update-progress' notifications when connected to untrusted servers, even though it inconsistently requires the device send its "unique-id" and now, maybe, per the subject line, its "version".  The question is, do we want to adhere to goal #2 or not.

What does adhering to goal #2 look like?  - we need to state that the "unique-id" and "version" (if we go for it) values in the URL are munged via a salted hashing algorithm (salt to prevent dictionary attacks).  Again, the *current* definition of "unique-id" has enough wiggle-room to enable vendors to hash these values if they want, but do we want to make it mandatory to be consistent?

What does NOT adhering to goal #2 look it? - I think that we say that devices MUST always send their IDevID certificate - this doesn't hurt (since the IDevID certificate doesn't contain much beyond serial number) while actually helping to prevent MiTM attacks (since a spoofed bootstrap server wouldn't know the device's IDevID private key).  But I'm conflicted if devices should send their progress updates to untrusted bootstrap servers, since the progress updates contain data above and beyond what devices would otherwise provide.  To address this, we might state that it's okay for devices to send progress updates to untrusted servers if and only if they are first able to verify the signature over the signed data, since that somewhat demonstrates the bootstrap server's authenticity.

Thoughts?

Kent // contributor