Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Sávyo Vinícius <> Tue, 08 December 2020 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F7733A0F0F for <>; Tue, 8 Dec 2020 06:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2wijoWN3rlZs for <>; Tue, 8 Dec 2020 06:41:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FD923A0D41 for <>; Tue, 8 Dec 2020 06:41:11 -0800 (PST)
Received: by with SMTP id u19so17845861edx.2 for <>; Tue, 08 Dec 2020 06:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UTYp8A0QOMjtcdGjh5S+wPc4o7ZPoohCE82JQIFD3OY=; b=CCKLtmuZ0uJB3CZ62vJ0RKZrNQRbXHZ2X6QDJm9nDAv1xdLLWZBGW7BnfbrqCqtIEp q75yBiAL454Aa6sySw9YDD5Tl/l0g4Vx9CvK5a3sPUjkef8CcetmAS7qecbYeMztcxXF 9GQLoQvf3ckKevuVV3ZOZGal/mJT6MXu2HLv3AcnsvEhU38O0uhpKu9TGn+QqSXl/hCf BfIzpbtx0oNWfEWQZB+Zk5InXsOYccgHvxYF44pfA/C8ih5ywHEE7moirCo/4Q6y/Rn8 JYdQ4q0088+puaIqFhyaqBwLclgbQroDBqQWqfL3rN+G0qk12BPgsoUN6iJUpOFAkxAL sl+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UTYp8A0QOMjtcdGjh5S+wPc4o7ZPoohCE82JQIFD3OY=; b=uZeQ9HCLGxpY3eORdyMxAsd21zVUfYQ5A2iMROjpTGNIAf7jflULxqOtgJH4/O+/JJ raT4QKecg+USXrCkefy3gILdXecth5qg0Hi9NbdNP1EOaZlDBPLifOGf2sc0uaD9KYAu q6u7o2/AfSBPPYW6Hso7OaEhNVl8vzCBtycdz4fUpkcztsEj1Q7IvgwvhOXnfq/l59tB AsYQeRVKe+Pg0HPTOLfqS9HmpXr9P8YtsPA6udAeSqK+/3J4j73vCgvqriK0VdHl2FEs ROwMQKrwFZAssCmlhI5veQH5msemY8915dWLTaxZvytNl47KhQ5Mhy0lCX8kY7himGCw pBRg==
X-Gm-Message-State: AOAM532Oe3IKDXpZmtC/C1wVHu9PUbJAuWBcotGeEscgah4zS84SPV9N 4oQaCGAc2JzvyH005wokfEXx8O3E/uOeqLq2k9dgRjSbJZ8ZAhooSJs=
X-Google-Smtp-Source: ABdhPJwOXAmuB4iBsPq09dURpxxHgLmP3dw31Nj6WCQNaPsPe0ipqPwcnO81YqT8U/T09dtKrSdBmQgJXlQEaoHuwfg=
X-Received: by 2002:a05:6402:30ac:: with SMTP id df12mr9511452edb.175.1607438469796; Tue, 08 Dec 2020 06:41:09 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <2741.1607381456@localhost>
In-Reply-To: <2741.1607381456@localhost>
From: Sávyo Vinícius <>
Date: Tue, 08 Dec 2020 11:40:57 -0300
Message-ID: <>
To: Michael Richardson <>
Content-Type: multipart/alternative; boundary="000000000000fd971105b5f4eeb7"
Archived-At: <>
Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Dec 2020 14:41:14 -0000

Michael Richardson <> wrote:

> and

I agree that we need to put as much effort as is possible to reinforce
security, but a
regulation becomes useless if it only allows the commercialization of
devices that
nobody can afford. Regulations need to create a tradeoff between protection
affordability and this turns harder in in-development-countries.

What can the IETF do?
> Mostly what we are already doing, which is to make it
> cheaper and easier to build products where the clients and the servers
> don't
> have to be vertically integrated.

... and we have a long way to go, but a starting point could be this issue
raised by RFC 8576 (section 5.5):

"Like all commercial devices, IoT devices have a given useful
lifetime. [...] A user should still be able to use and
perhaps even update the device.  This requires for some form of
authorization handover.

[...] CyanogenMod for Android devices and OpenWrt for home routers
are two such instances where users have been able to use and update
their devices even after the official EOL. Admittedly, it is not easy
for an average user to install and configure their devices on their
own.  With the deployment of millions of IoT devices, simpler mechanisms
are needed to allow users to add new trust anchors [RFC6024] and install
software and firmware from other sources once the device is EOL."

So how should we tackle this?
Develop a framework to simplify the third part development of
software/firmware updates after the EOL?
And how to integrate SUIT work on it?