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 "atthe 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
