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

[Zhen Cao <[e-mail]>]

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
<[e-mail]> 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.
>
>
>
>
>
>