Hi Christian, Thank you again for reviewing this document, and a very happy new year of 2018 :)
Could you help review the update according to authors' update and see if you have further concerns? so that as shepherd I can see if I can move it further. BR, Zhen On Tue, Dec 26, 2017 at 12:27 AM, Mohit Sethi <mohit.m.se...@ericsson.com> wrote: > 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. > > > > > > _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
