Re: [Iotops] Relevant ETSI work on consumer IoT security

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 09 November 2022 17:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD61BC14CE47 for <iotops@ietfa.amsl.com>; Wed, 9 Nov 2022 09:55:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLy59MCbMbL9 for <iotops@ietfa.amsl.com>; Wed, 9 Nov 2022 09:55:37 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A405FC14F75F for <iotops@ietf.org>; Wed, 9 Nov 2022 09:55:37 -0800 (PST)
Received: from dyas.sandelman.ca (unknown [IPv6:2001:67c:370:1998:c16e:e75a:a600:3913]) by relay.sandelman.ca (Postfix) with ESMTPS id AF46B1F4AF; Wed, 9 Nov 2022 17:55:33 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 0EF4FA01CD; Wed, 9 Nov 2022 17:55:33 +0000 (GMT)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 0CC13A0109; Wed, 9 Nov 2022 17:55:33 +0000 (GMT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jasper Pandza <jasper.pandza=40dcms.gov.uk@dmarc.ietf.org>, iotops@ietf.org
In-reply-to: <CAHOkwd9qnM6MZB0Vwck+qMUiT_zWPNik=EeN=_ef01J3+GX09Q@mail.gmail.com>
References: <CAHOkwd9qnM6MZB0Vwck+qMUiT_zWPNik=EeN=_ef01J3+GX09Q@mail.gmail.com>
Comments: In-reply-to Jasper Pandza <jasper.pandza=40dcms.gov.uk@dmarc.ietf.org> message dated "Wed, 09 Nov 2022 16:12:50 +0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 09 Nov 2022 17:55:33 +0000
Message-ID: <422886.1668016533@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/qMf8S1dRBztxAYafZPGsrnkPZDc>
Subject: Re: [Iotops] Relevant ETSI work on consumer IoT security
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2022 17:55:41 -0000

Jasper Pandza <jasper.pandza=40dcms.gov.uk@dmarc.ietf.org> wrote:
    > With reference to draft-moran-iot-nets-02 and as promised in my
    > intervention yesterday, here is an overview of ETSI’s work on security for
    > connected consumer devices.

    > EN 303 645
    > <https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf>
    > – baseline requirements for consumer IoT security. Worth noting this
    > includes both technical and procedural (e.g. vulnerability disclosure)
    > requirements. Whilst it says “European Standard (EN)”, this work had
    > contributions from a global stakeholder community.

Jasper thank you bringing this up.

And while there have been many carrots (and I was a subject-matter expert
for: https://www.iotsecurityfoundation.org/consumer-iot/ which dealt with
three key parts of 303645),   we still don't know what kind of sticks will be
applied.

What we really need is some real (public) consequences for shipping devices
that do not get this right.  Until when the CFO notices will we get some real
progress.

draft-richardson-t2trg-idevid-considerations was in part a response to
getting devices to ship with something-unique inserted at factory.
(whether it's a unique password or a unique private key...)

I've heard at previous RIPE meetings about potential EU regulations in this
space.  What's the UK situation?  Any new progress?  It would be great to
hear about this at a future IOTOPS meeting.

    > So, at least for the consumer domain, I think we have already gone a
    > significant way in addressing the problem statement identified in section 1
    > of the above paper.

    > The relevant ETSI committee (TC CYBER) would welcome further contributions,
    > including from the IETF community. I can make introductions if needed.



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-