Re: [Lwip] Secdir early review of draft-ietf-lwig-crypto-sensors-04

[Mohit Sethi <[e-mail]>]

Dear Christian,

Thanks for the detailed review and positive comments. We have now 
submitted an updated version which can be found here: 
https://tools.ietf.org/html/draft-ietf-lwig-crypto-sensors-05. The diff 
from the previous version can be found here: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-crypto-sensors-05.

You had raised an important point about identifiers and privacy. To 
address this, we have added new text in section 3 (Challenges), section 
4.1 (Provisioning) and section 8.1 (Feasibility). I provide snippets of 
the added text here for your convenience:

> small resource-constrained devices
>     are often shipped with a single static identity.  In many cases, it
>     is a single raw public key.  These long-term static identities makes
>     it easy to track the devices (and their owners) when they move.  The
>     static identities may also allow an attacker to track these devices
>     across ownership changes.
> long-term static identities
>     negatively affect the privacy of the devices and their owners.
>     Therefore, it is beneficial for devices to generate new identities at
>     appropriate times during their lifecycle.  For example, after a
>     factory reset or an ownership handover.  Thus, in our proposed
>     deployment model, the devices would generate a new asymmetric key
>     pair and use the new public-key P' to generate the new identity I'.
>     It is also desirable that these identities are only used during the
>     provisioning stage.  Temporary identities (such as IPv6 addresses)
>     can be used for network communication protocols once the device is
>     operational.
>   we
>     did note that it is possible for such devices to generate a new key
>     pair.  Given that this operation would only occur in rare
>     circumstances (such as a factory reset or ownership change) and its
>     potential privacy benefits, developers should provide mechanisms for
>     generating new identities.  It is however extremely important to note
>     that the security of this operation relies on access to
>     cryptographic-quality randomness.

Let us know if the ideas or the text here is not sufficient.

--Mohit
On 10/15/2017 07:38 PM, Christian Huitema wrote:
> Reviewer: Christian Huitema
> Review result: Has Nits
>
> This is an early review of draft-ietf-lwig-crypto-sensors-04 on behalf of the Security Directorate.
>
> The document is almost ready, but would benefit from a bit more further work.
>
> This draft examines a series of risks and challenges posed by securing small devices,
> proposes solutions for provisioning, and an architecture for securing the devices.
> The implementation experience section (section 8) provides measurements for the
> memory and CPU costs of various cryptographic operations using the Arduino
> platform. It will be good to see these results published and become a useful
> reference in further debates. In fact, I like this document a lot. My only
> concern is that it misses an opportunity to discuss identifiers and privacy.
>   
> I like the discussion of platform constraints in section 3, and the statement that "at
> the end of the day, if strong cryptographic security is needed, the implementations
> have to support that." I think it is an important message, and it it might be
> good to reinfore it with examples. For example, we do ship medecine in child-proof
> containers. It would be cheaper to use ordinary containers, but we pay the cost
> because as a society we want to mitigate the risk of children mistaking pills for candy.
> Similarly, it is cheaper to build devices with no security, but we may want society
> to mandate that risks should be mitigated.
>
> The challenge section, and the document in general, would be even better if it included
> a discussion of identifiers and privacy. The general concern is that because small
> devices have limited resource, they end up using just one identity, maybe just one
> public key. This makes them easy to track when they move, and by extension track the
> movements of their owners for wearable devices, or associated objects such as cars for
> general devices. There are certainly mitigations, such as provisioning new identities
> at appropriate times, or using temporary identities in communication protocols, but
> these mitigations certainly require the kind of trade-offs discussed in the draft. It
> would thus be very nice to introduce the privacy challenges in the "challenge"
> section, and to discuss the privacy mitigations in the other sections, e.g., architecture
> and provisioning.
>
>
>
>
>