From nobody Sun Nov 1 09:36:45 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 580EF3A0779; Sun, 1 Nov 2020 09:36:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-suit-architecture@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160425219933.2164.12165140117377106860@ietfa.amsl.com> Date: Sun, 01 Nov 2020 09:36:39 -0800 Archived-At: Subject: [Suit] Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 17:36:40 -0000 Barry Leiba has entered the following ballot position for draft-ietf-suit-architecture-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice work on this; thanks. I have a bunch of comments, but all minor. — Section 1 — Firmware updates can help to fix security vulnerabilities and are considered to be an important building block in securing IoT devices. Nit: “firmware updates” is plural, and “building block” is singular. I think it’s actually *doing* the updates that’s the building block, not he updates themselves. And you can just make the statement, without “are considered”. How do you like this version?: NEW Firmware updates can help to fix security vulnerabilities, and performing updates is an important building block in securing IoT devices. END Due to rising concerns about insecure IoT devices the Internet Architecture Board (IAB) organized a 'Workshop on Internet of Things (IoT) Software Update (IOTSU)', which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at the bigger picture. A report about this workshop can be found at [RFC8240]. The workshop revealed a number of challenges for developers and led to the formation of the IETF Software Updates for Internet of Things (SUIT) working group. The details of when and where the workshop happened isn’t important here, and it’s rigt up front in 8240 anyway. I suggest trimming that, because the important part is pointing people to the worshop report and saying what’s in the next sentence about the formation of the SUIT WG. NEW Due to rising concerns about insecure IoT devices the Internet Architecture Board (IAB) organized a 'Workshop on Internet of Things (IoT) Software Update (IOTSU)' [RFC8240] to take a look at the bigger picture. The workshop revealed a number of challenges for developers and led to the formation of the IETF Software Updates for Internet of Things (SUIT) working group. END Firmware updates are not only done to fix bugs, but they can also add new functionality, and re-configure Grammar nit: “Firmware updates are done not only to fix bugs, but also to add new functionality and to reconfigure” Unlike higher end devices, like laptops and desktop PCs, many IoT devices do not have user interfaces and support for unattended updates is, therefore, essential for the design of a practical My first reading of this was that “many IoT devices do not have user interfaces and support for unattended updates.” I had to read it again to correctly interpret the sentence. If you replace “interfaces and” with “interfaces;” it fixes that problem easily. using pre-configured hostnames or [RFC6763] DNS-SD. The citation should go after “DNS-SD”. — Section 2.1 — - Firmware Image: The firmware image, or image, is a binary The “or image” seems odd there. Maybe like this?: NEW - Firmware Image: The firmware image, or simply the “image”, is a binary END — Section 2.3 — The deployment of status trackers is flexible and may be found at cloud-based servers, on-premise servers, or may be embedded in edge computing devices. (Odd line-break here...) Nit: the list is not parallel, and the intro doesnt read right. Try this?: NEW The deployment of status trackers is flexible: they may be found at cloud-based servers or on-premise servers, or they may be embedded in edge computing devices. END — Section 3 — images to the firmware server and to initiate an update him- or herself. Nit: I suggest avoiding the awkwardness by saying “and to initiate an update directly.” As a first step in the firmware update process, the status tracker client needs to be made aware of the availability of a new firmware update by the status tracker server. Nit: passive voice makes this more awkward than it needs to be, especially as you have a clear subject already (the server). Why not make it active?: NEW As a first step in the firmware update process, the status tracker server needs to inform the status tracker client that a new firmware update is available. END - Using a hybrid approach the server-side of the status tracker pushes notifications of availability of an update to the client side and requests the firmware consumer to pull the manifest and the firmware image from the firmware server. As written, this is exactly the same as the server-initiated scenario. In both cases, the server tells the client that an update is available, and the firmware consumer fetches the manifest and image. What is the difference meant to be? Do one or both of the descriptions need to be tweaked? (I’m guessing that the server-initiated description should be changed to say that the server pushes the manifest and image, rather than waiting for the client to fetch it... yes?) If the firmware consumer has downloaded a new firmware image and is ready to install it, to initiate the installation, it may - either need to wait for a trigger from the status tracker, - or trigger the update automatically, - or go through a more complex decision making process to determine the appropriate timing for an update. Are those dashes meant to be bullets in a list, and so is this a formatting glitch? Devices must not fail when a disruption occurs during the update process. For example, a power failure or network disruption during the update process must not cause the device to fail. Nit: why not merge these two sentences?: NEW Devices must not fail when a disruption, such as a power failure or network interruption, occurs during the update process. END — Section 4.1 — - The bootloader needs to fetch the manifest (or manifest-alike headers) from nonvolatile storage What are “manifest-alike headers”? This allows to share information about the current firmware version “Allows to share” doesn’t work in English: you need a subject, “allows to share ”. If you don’t have a subject, you can say “allows the sharing of information...”. — Section 6 — A manifest may not only be used to protect firmware images but also configuration data such as network credentials Similar to a comment above, this has “not only” misplaced: NEW A manifest may be used to protect not only firmware images but also configuration data such as network credentials END From nobody Mon Nov 2 15:37:33 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9B63A1564; Mon, 2 Nov 2020 15:37:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: suit@ietf.org Message-ID: <160436024580.20460.6202324294470603493@ietfa.amsl.com> Date: Mon, 02 Nov 2020 15:37:25 -0800 Archived-At: Subject: [Suit] I-D Action: draft-ietf-suit-manifest-10.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:37:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Software Updates for Internet of Things WG of the IETF. Title : A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest Authors : Brendan Moran Hannes Tschofenig Henk Birkholz Koen Zandberg Filename : draft-ietf-suit-manifest-10.txt Pages : 111 Date : 2020-11-02 Abstract: This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the that code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-suit-manifest-10 https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-suit-manifest-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 4 10:16:01 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7545C3A13F8; Wed, 4 Nov 2020 10:15:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-suit-architecture@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Russ Housley X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <160451375602.7602.11341071574968700142@ietfa.amsl.com> Date: Wed, 04 Nov 2020 10:15:56 -0800 Archived-At: Subject: [Suit] Alvaro Retana's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:15:57 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-suit-architecture-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I was surprised to see that there no Normative references -- are there no other documents required to be read to understand the architecture? It seems to me that I-D.ietf-suit-information-model should be a Normative reference because it contains an "in-depth examination of the security considerations of the architecture" (this document). From nobody Wed Nov 4 10:25:34 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225093A147E for ; Wed, 4 Nov 2020 10:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLaxPnXbVW6Q for ; Wed, 4 Nov 2020 10:25:31 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC9F3A147D for ; Wed, 4 Nov 2020 10:25:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D2417300AF2 for ; Wed, 4 Nov 2020 13:20:13 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MqYkjhj4_VcD for ; Wed, 4 Nov 2020 13:20:11 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 409223005D5; Wed, 4 Nov 2020 13:20:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <160451375602.7602.11341071574968700142@ietfa.amsl.com> Date: Wed, 4 Nov 2020 13:20:12 -0500 Cc: IESG , draft-ietf-suit-architecture@ietf.org, suit-chairs@ietf.org, suit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <65052D1A-B1C2-4A42-88EF-6A9CC1840D72@vigilsec.com> References: <160451375602.7602.11341071574968700142@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Suit] Alvaro Retana's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:25:33 -0000 Alvaro: It is an informational document, and many informational documents only = have informational references. Russ > On Nov 4, 2020, at 1:15 PM, Alvaro Retana via Datatracker = wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-suit-architecture-14: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I was surprised to see that there no Normative references -- are there = no other > documents required to be read to understand the architecture? >=20 > It seems to me that I-D.ietf-suit-information-model should be a = Normative > reference because it contains an "in-depth examination of the security > considerations of the architecture" (this document). >=20 >=20 >=20 From nobody Wed Nov 4 11:30:07 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58943A0FC6; Wed, 4 Nov 2020 11:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHagY7OZ87gC; Wed, 4 Nov 2020 11:30:04 -0800 (PST) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158CA3A0FC2; Wed, 4 Nov 2020 11:30:04 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id dk16so30825255ejb.12; Wed, 04 Nov 2020 11:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/tjksyEG5xTYR7teZcQGIb0bmNmX0PRbB6Xu1/QXy0k=; b=l/NMzQTJqZgfogI/5tFWbfQ1vmODHWxYD3T0hx3yk4/f2tGHv0hFwlLj402IYuFLwo sRAU1tKMa8qPnGBVRqU1m4689MIH2cIs/H0lzGlgbIBjMi1X582qFvF2J7EyMiWScZUO WnOfhSa7qz5FubHOHLqI+IqYE9XDP/gXtn4qEpnotp0Xb2hCik2+phtQbBd4r0J7LCt5 jZB4zp1bLGKUPjx6q/+NGqo1KfPSNVZ8OzZd0FQsEFA3jzmUqpNjiQRnaBBgh0kE8Xug +mSpB/LdtwpJ6fhpVWUvOHekD/UYQJp+ddePq4MWg8lG5b/5WTCLINwqX18jSKCVr1JL 19mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/tjksyEG5xTYR7teZcQGIb0bmNmX0PRbB6Xu1/QXy0k=; b=o8MbTtCdzLnH0Y+ljKV0rMRfwtXhqNT4Nc2vN7QnZt8r3AcxCyXEhNFp9niTx+uJPj q8qP6Sj8Yuu2R9CZz5oM756pWh3FFWg0b9rxAHFLF01l9adFiX5r9wNj/hMYWl7g3wTy A6iNeQL6PRO41hcn4quORbiuvOD/Fvuj5cjEHP0L+dGn0F3O+QPjarlFTasD6DPDEk6M vvGTua3ESInQpU22pu9ckl9p5edO3weXntaqXOneVaXS3UQcyEEpibU6z5V5CZHdklum kru+tRMhM+s7RSKOCgUOvAfJIGhy1IdCrwiDVg2UhO0ZNy7jjoWyRPvapciBY7wcX9MP oQ1Q== X-Gm-Message-State: AOAM5309fDU7TSB77xAohfGih3snxq8VarGNFyJzHaElhPkMs4mVMOW1 h1yrlWiZNsrN6ZRHd8YgdtDcjPLKffzB6J9bpf4= X-Google-Smtp-Source: ABdhPJxoCvKijo+o047EPtTaQ5MyfkHQxuw2uOh32sNi5788sibdtl52dswWI3qHnEXKyek3uR+bbvrmlLhgnqRReGs= X-Received: by 2002:a17:906:f744:: with SMTP id jp4mr7804926ejb.122.1604518202564; Wed, 04 Nov 2020 11:30:02 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Nov 2020 14:30:02 -0500 From: Alvaro Retana In-Reply-To: <65052D1A-B1C2-4A42-88EF-6A9CC1840D72@vigilsec.com> References: <160451375602.7602.11341071574968700142@ietfa.amsl.com> <65052D1A-B1C2-4A42-88EF-6A9CC1840D72@vigilsec.com> MIME-Version: 1.0 Date: Wed, 4 Nov 2020 14:30:02 -0500 Message-ID: To: Russ Housley Cc: suit-chairs@ietf.org, IESG , suit@ietf.org, draft-ietf-suit-architecture@ietf.org Content-Type: multipart/alternative; boundary="0000000000007fe48605b34d010c" Archived-At: Subject: Re: [Suit] Alvaro Retana's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:30:06 -0000 --0000000000007fe48605b34d010c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Russ: Hi! Yes=E2=80=A6but the definition of a Normative reference is independent of t= he status of the document. [1] In any case, this is a non-blocking comment. I trust the authors and the AD to do the right thing. Thanks! Alvaro. [1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-ref= erences/ On November 4, 2020 at 1:20:16 PM, Russ Housley (housley@vigilsec.com) wrote: Alvaro: It is an informational document, and many informational documents only have informational references. Russ > On Nov 4, 2020, at 1:15 PM, Alvaro Retana via Datatracker < noreply@ietf.org> wrote: > > Alvaro Retana has entered the following ballot position for > draft-ietf-suit-architecture-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I was surprised to see that there no Normative references -- are there no other > documents required to be read to understand the architecture? > > It seems to me that I-D.ietf-suit-information-model should be a Normative > reference because it contains an "in-depth examination of the security > considerations of the architecture" (this document). > > > --0000000000007fe48605b34d010c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Russ:

Hi!

Y= es=E2=80=A6but the definition of a Normative reference is independent of th= e status of the document. [1]

In any case, this is a non-blocking comment.=C2=A0 I trust the a= uthors and the AD to do the right thing.

Thanks!

Alvaro.

=

On November 4, 2020 at 1:20:16 PM, Russ Housley (housley@vigilsec.com) wrote:

Alvaro:

It is an informational document, and many informational documents only = have informational references.

Russ


> On Nov 4, 2020, at 1:15 PM, Alvaro Retana via Datatracker <noreply@ietf.org> wrote:
> =20
> Alvaro Retana has entered the following ballot position for
> draft-ietf-suit-architecture-14: No Objection
> =20
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut= this
> introductory paragraph, however.)
> =20
> =20
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT positions.
> =20
> =20
> The document, along with other ballot positions, can be found here= :
> https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/
> =20
> =20
> =20
> ------------------------------------------------------------------= ----
> COMMENT:
> ------------------------------------------------------------------= ----
> =20
> I was surprised to see that there no Normative references -- are t= here no other
> documents required to be read to understand the architecture?
> =20
> It seems to me that I-D.ietf-suit-information-model should be a No= rmative
> reference because it contains an "in-depth examination of the= security
> considerations of the architecture" (this document).
> =20
> =20
> =20

<= /body> --0000000000007fe48605b34d010c-- From nobody Thu Nov 5 01:37:46 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA893A0DEB; Thu, 5 Nov 2020 01:37:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-suit-architecture@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Russ Housley , housley@vigilsec.com, mohit.m.sethi@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160456906093.24545.13517793229178865274@ietfa.amsl.com> Date: Thu, 05 Nov 2020 01:37:41 -0800 Archived-At: Subject: [Suit] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-suit-architecture-14=3A_=28with_COMMENT=29?= X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 09:37:42 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-suit-architecture-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please add reference to LwM2M in Section 1. Please also address all comments raised by Mohit Sethi during the IoT directorate review (I saw that Brendan has already replied): https://datatracker.ietf.org/doc/review-ietf-suit-architecture-13-iotdir-telechat-sethi-2020-10-20/ I hope that this helps to improve the document, Regards, -éric From nobody Thu Nov 5 01:38:55 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 557023A0E08; Thu, 5 Nov 2020 01:38:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-suit-architecture@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160456913386.24093.10722400425795162498@ietfa.amsl.com> Date: Thu, 05 Nov 2020 01:38:54 -0800 Archived-At: Subject: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 09:38:54 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-suit-architecture-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Does the XIP case mean that repeated firmware updates would have potential to cause undue wear on the fixed flash cells that hold the firmware image? If so, this might be noted in the security considerations. I am not sure that I have fully digested Bob Briscoe's detailed review comments, but it seems like we may want to continue to reflect on which portions of the architecture will be optional to implement, and how we might indicate that in the document. I also made a pull request for some editorial nits at https://github.com/suit-wg/architecture/pull/15 . Section 1 otherwise difficult. Firmware updates for IoT devices are expected to work automatically, i.e. without user involvement. Conversely, IoT devices are expected to account for user preferences and consent when scheduling updates. Automatic I can't quite tell if the "Conversely" case is intending to refer to IoT or non-IoT devices. The firmware update process has to ensure that - The firmware image is authenticated and integrity protected. [...] - The firmware image can be confidentiality protected so that attempts by an adversary to recover the plaintext binary can be [...] Perhaps it's just because Bob Briscoe's comments are fresh in my mind, but there seems to be something of a mismatch across these texts -- we "have to ensure" that the firmware *is* authenticated and integrity protected, but only that the image *can be* confidentiality protected. Is it really the case that we can ensure that an update process *can be* confidentiality protected, or is the confidentiality requirement more of a requirement on the architecture than on actual deployment? While the IETF standardization work has been focused on the manifest format, a fully interoperable solution needs more than a standardized manifest. For example, protocols for transferring firmware images and manifests to the device need to be available as well as the status tracker functionality. Devices also require a mechanism to discover the status tracker(s) and/or firmware servers, for example using pre-configured hostnames or [RFC6763] DNS-SD. These building blocks have been developed by various organizations under the umbrella of an IoT device management solution. The LwM2M protocol is one IoT device management protocol. We might put some forward references to things we do cover (like status tracker(s)), and a reference for LwM2M as well. Section 3 Hence, the following components are necessary on a device for a firmware update solution: [...] - a status tracker. Earlier we said that having the status tracker on the device was fairly uncommon. Section 7 time horizon for quantum-accelerated key extraction. The worst-case estimate, at time of writing, for the time horizon to key extraction with quantum acceleration is approximately 2030, based on current research [quantum-factorization]. I'm not sure that I see how the reference suports the "approximately 2030" statement. From nobody Thu Nov 5 04:05:27 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8043A1798; Thu, 5 Nov 2020 04:05:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-suit-architecture@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160457792503.2410.4847314047672327887@ietfa.amsl.com> Date: Thu, 05 Nov 2020 04:05:25 -0800 Archived-At: Subject: [Suit] Robert Wilton's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 12:05:25 -0000 Robert Wilton has entered the following ballot position for draft-ietf-suit-architecture-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document. I found it informative and interesting. One minor comment: 7. Securing Firmware Updates The information that is encrypted individually for each device/ recipient must maintain friendliness to Content Distribution Networks, bulk storage, and broadcast protocols. Although I think that I understand the intent here, I'm not sure whether friendliness is the best choice of term here. I presume that it means "must be done in a way that is usable with". Regards, Rob From nobody Tue Nov 10 17:03:14 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 618243A1276; Tue, 10 Nov 2020 17:03:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Evens via Datatracker To: Cc: last-call@ietf.org, suit@ietf.org, draft-ietf-suit-information-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160505658534.5583.16251883250744786928@ietfa.amsl.com> Reply-To: Tim Evens Date: Tue, 10 Nov 2020 17:03:05 -0800 Archived-At: Subject: [Suit] Genart last call review of draft-ietf-suit-information-model-08 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 01:03:06 -0000 Reviewer: Tim Evens Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-suit-information-model-?? Reviewer: Tim Evens Review Date: 2020-11-10 IETF LC End Date: 2020-11-11 IESG Telechat date: Not scheduled for a telechat Summary: Looks good. Major issues: Minor issues: Nits/editorial comments: From nobody Wed Nov 11 08:24:22 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9567F3A108A for ; Wed, 11 Nov 2020 08:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4E30gi_52e4 for ; Wed, 11 Nov 2020 08:24:17 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F69B3A03FB for ; Wed, 11 Nov 2020 08:24:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B1330300B76 for ; Wed, 11 Nov 2020 11:24:13 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q7DN1L3gkwo3 for ; Wed, 11 Nov 2020 11:24:12 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 32FD0300A9E for ; Wed, 11 Nov 2020 11:24:12 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: Date: Wed, 11 Nov 2020 11:24:13 -0500 To: suit X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [Suit] Please give your feedback to NomCom X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:24:21 -0000 Please give your feedback to NomCom as requested below. Russ ---------------------------- NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC = Board, and IETF Trust. We need more input from the community both on = specific nominees and on over-arching topics regarding what the = community wants from these specific groups and wants from its leadership = in general. We need *your* input. ** Deadline for community feedback is Friday November 20. ** We've paid attention to discussions on the ietf list. Issues raised = there have been brought up in interviews. We've also asked questions of nominees based on feedback received, and = based on the "Topics" that people said were important. We're listening to you.=20 But most of the input to date has come from a few consistently vocal = people. We need to hear from more of you. I scheduled our office hours during the 2 weeks before next week's IETF, = because IETF week is so busy. We have one more left (18:00-19:00 UTC = November 11). No-one but NomCom members showed up for our first 3. =E2=98=B9= If there is demand for more office hours, I'll schedule them; but this = really doesn't seem to be the preferred format for input. Most input is coming in as either=20 - email to nomcom20@ietf.org - feedback on https://datatracker.ietf.org/nomcom/2020/feedback/ On the feedback page, the specific nominees are all listed at the top. = General Topics are at the bottom. We pay attention to all the comments we get through these channels. I'll also try to hang out in Gather.Town during IETF breaks next week.=20= I'm not going to have a specific NomCom area in Gather.Town, because it = was really lonely hanging out there during IETF 108. But please feel free to hunt me down and bend my ear -- on NomCom issues = or just to chat. I miss seeing all of y'all! Barbara Barbara Stark NomCom 2020 Chair From nobody Wed Nov 18 14:06:17 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6E03A0DAC; Wed, 18 Nov 2020 14:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=DgYqf8uU; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=DgYqf8uU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV_1Uk6G85L9; Wed, 18 Nov 2020 14:06:06 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8433A0DB5; Wed, 18 Nov 2020 14:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tUyrxpiTI4HfY1yvxFvE6HucmA5qgwecAlUyX5Vtqis=; b=DgYqf8uUvQ6mfmtZnzvSuuUX8dbSNJ5zN0nThlVaUsHrMu/b39X9rX5/NK6UXuShhXowatoegbmLEle7YrIMnP4h/0SUKhhx4QSEt8bvmhNvgk65Qf6aPZEJnUbVvfY+1z5gSkZRe+FhXCFQVEdmf7GnuP0kGX0W4D4z3pGuDs0= Received: from AM6P195CA0033.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:81::46) by AM9PR08MB6193.eurprd08.prod.outlook.com (2603:10a6:20b:282::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Wed, 18 Nov 2020 22:05:52 +0000 Received: from AM5EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:81:cafe::6) by AM6P195CA0033.outlook.office365.com (2603:10a6:209:81::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Wed, 18 Nov 2020 22:05:52 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT049.mail.protection.outlook.com (10.152.17.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Wed, 18 Nov 2020 22:05:52 +0000 Received: ("Tessian outbound d6c201accd3c:v71"); Wed, 18 Nov 2020 22:05:52 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 6570d17567ee91a0 X-CR-MTA-TID: 64aa7808 Received: from 27545d210f84.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9256CF65-0D0A-41E7-8A32-D25B60429A26.1; Wed, 18 Nov 2020 22:05:46 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 27545d210f84.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 18 Nov 2020 22:05:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KfRwwYU94cDaP5jdRTbCyjtvmtzRp3NXU1yt562hmN3+lgT1fh8nsxAmJ87kT5sKX/s/UhhQ6uRWAkVVSsI4O0LEo3O3yU6mqFd8Z+FbZbexh7D3N/kLFCVh3eCecBp+m+A5vROcBlZSlVhJikH2TyH/fWy94FsI8LMDY0q66enJOol9icHXVgdeYxwvTFkq2wkZJ2AAKlWasSDfxkx2uxsouq9e54jbSImTdPhZmIsc1M4JGdxZ82CDILvtT9hOTiIzPEjJnO9AY0AyaNrP04c/w6l60op9R55ZqAPrgAwvdzxgeYm5JPZkzgHRSuF/FtYpLdauMhaRuXsSVLszWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tUyrxpiTI4HfY1yvxFvE6HucmA5qgwecAlUyX5Vtqis=; b=mJJQ4+mD5wTmxzEDgzKk958j/A/w3TyzX6u08IhJpRKhLL9l20wf7CbHypOsLpLfp1RQ1VXfc+hY/Cc19ZCosBc9VnxjtZLnDsXWIOBZTl99Zu1PrvuRKZJr6y3S4vkPzH0beh8IJiODZO9wjWmBnsD2Ln/u3JVr0FZTBpuCMT09v91Pw0F2jRJ0KCp4uFujr4MuaveQsfsH7tp83BLonM99cXQvrFHZmzUdTpj4fvD/42UmDOSVosb1O+ORulHKoR7pWU790AsiU94X2NjTFnJZ5bsPXxPAASes6ouhC2YBmRD9b5VCcKMF65v0ddn+TR4vp2ShTVqTSd4fDXqIZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tUyrxpiTI4HfY1yvxFvE6HucmA5qgwecAlUyX5Vtqis=; b=DgYqf8uUvQ6mfmtZnzvSuuUX8dbSNJ5zN0nThlVaUsHrMu/b39X9rX5/NK6UXuShhXowatoegbmLEle7YrIMnP4h/0SUKhhx4QSEt8bvmhNvgk65Qf6aPZEJnUbVvfY+1z5gSkZRe+FhXCFQVEdmf7GnuP0kGX0W4D4z3pGuDs0= Received: from AM9PR08MB6146.eurprd08.prod.outlook.com (2603:10a6:20b:2db::17) by AM9PR08MB6097.eurprd08.prod.outlook.com (2603:10a6:20b:280::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Wed, 18 Nov 2020 22:05:45 +0000 Received: from AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5]) by AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5%4]) with mapi id 15.20.3589.021; Wed, 18 Nov 2020 22:05:45 +0000 From: Brendan Moran To: Benjamin Kaduk CC: The IESG , "draft-ietf-suit-architecture@ietf.org" , "suit-chairs@ietf.org" , suit , Russ Housley Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) Thread-Index: AQHWs1eEcjyU/Z29aUm24cS5YMgJianOhzuA Date: Wed, 18 Nov 2020 22:05:44 +0000 Message-ID: References: <160456913386.24093.10722400425795162498@ietfa.amsl.com> In-Reply-To: <160456913386.24093.10722400425795162498@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) Authentication-Results-Original: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.7.184.196] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 4e67a4ba-3db7-4182-f50e-08d88c0e1d93 x-ms-traffictypediagnostic: AM9PR08MB6097:|AM9PR08MB6193: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: oUT+1yA3J/0OS9nolpUqUUMEphi478GdQflrY6lhEw17eGRn71ZYQgiJTNN5waj1cojcJxZYfbq3mZdRbLKgzdVZXwn0lhOAOdHKz/hSla+yuW6fSsuNBHD4Em/UXKDUL2RwlJqzbPi+md0LQ01f9tlOEFYxTJY/xxYbaDyEDVM0LmkjwT1yhbPxVdEJL18ASGf1K+jPogfpOVBi/13Es90C5y6Z2+w0Jilzl66Z37JbgVBFTvdk59Elmgvm3WSKlUJCSVzNaPcaYeP29EJlXUwOvsx/RYq/EG6h4fo5GS9gBlzOOjklgzcWmAd2iDWhLpWlMlZFQLFfX8Snk0vBxHQYmRI75q+JHUQFh2oV/rivfo2u2J6Uz8GlC9yBsnOXCrDG5458biKk3IUylEz3lQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR08MB6146.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(136003)(396003)(346002)(376002)(366004)(71200400001)(66946007)(316002)(6916009)(26005)(33656002)(4326008)(66556008)(66476007)(8936002)(36756003)(6506007)(66446008)(54906003)(91956017)(5660300002)(76116006)(53546011)(64756008)(2616005)(8676002)(6486002)(86362001)(83380400001)(186003)(6512007)(2906002)(966005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Oj5yNSEZvFNUUdBnUEBXwfYdfrW8JiLYthot9W/WNvVNgsDQ1XILJYMln3750POlvQf2mdGJPBh8Tvb36EfcGmgTENRQ2u4ftoWPmOYBACu31wcD48P1s1darbWOQ5ysJ2i18UEsgcYodppX2pFFQXRhjbeFUvTJt7OBX5NEp5BNm4bBHBHBAoeUC6iOAqJfEJDzk4+YVfefIq8iW+CTzPOiN/Eq5DXuEc2lajwgi3KXFcFJfXTmTc31V+UoSzpFIBwdzI3wCC5m8BodFVezpYgcQ3CYl0l4AD2pa7MgEfgZ4jaK3DAJ/GNjHyQnDXmkAydGpsTtWyz0J+ZPXh+eWltJnVVpt0rmIdZGZDihe5yUT6nwTUvS75AAWA57pLdNE/7WKU5443iluNKgeS1OVm00nqPy1wEXop8e/a6U3po6Z2ED5/RbKhDs2UKLibZFb7tpyxH2Kdx6xbA7o0lB0/ujKDbNwu5VPq2bQ4VHN68n66JXxsy9WRtgZmde3RxgTqEKyauo4FT9A1EzzHdgZxzeLSJcNuS7fu2xjQ5/JwyUU08+xo//eyUB71Sv4zaaS5D6gMQZCk+k7rWmvEXwaMSdVql6ap95hwWV4kRJOSieVIjhX60cZJBTFlZkVRGc2Fo5Lm2OXZe2LbSl3gRQU7kS/4TkI9y/ebXUAok/DUljNGECjTFftcW/r1nwIMdXDKNbmbW1xlQISqiLpLI2N/6kYZl3Rp4asoGFzyfP5gyMTl6TCxtOuWMiLjjwt4gmCC5XJjQ8Z143uvJ0lONDrCHsZidalu0nrGsrfZLkzrebb9pr7nxoaPhhvKlKD4bk8BQWcmrc/b0J4YfnzNd5YfeQaVbNgptdT8padSdIHIem0chf01BRK1AZTBX+NB10EG1+3QT417H79BUrUz51iA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <7DC6F3F8BFB04E4B94BBECBC0FE4AF1C@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6097 Original-Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d8c836d4-ee99-4927-c4c8-08d88c0e191c X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +bhYqzzak8BIKQPPiyRaIe0+jZj6DZk9HyP+RbsVP2/3T8JPEYmTd8DJ2p7i2CERRJ2OvB/h2FpYO8oIjZJEl/x89gSWJaxfMUVPvqjqLKz/ywsMxF/HMqR0zwNqU3nxBFZfZb0gln8WaT8nmCd22EliDpy7dsX1y8yRFKvyO2VRrM5w1CLft3OLAR5inxuOeZ1czy3ctXZigxoc0TjbS32mOGw26QfbWgEAb8eOc8GrJmnWrJ0WwKXg8mfxWX8h8f30cVUrL8WyHYfymZzcyqsifAJAa9S85zcC14UUQ8pbMKDJVU415KIFYsfbxEyljJVWiq/lE0B1YQ206wzxmBym9CwiQ3NKc1X6G7jzbflcojWVAlWYpiVHuSYeaaGM3wXuqRzaNNbXE8kHzRYVVoZn+o8Md9roA2zl2TyHeu92aah55kjGDEFS3RODgkkYdBfBEEwNCX4UTSE/H49o374Y+2l6MUVLwdEsDlYUCF4= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(136003)(396003)(39850400004)(376002)(46966005)(450100002)(107886003)(82310400003)(83380400001)(186003)(36756003)(33656002)(8676002)(6512007)(6862004)(26005)(4326008)(6506007)(5660300002)(53546011)(966005)(54906003)(478600001)(36906005)(8936002)(86362001)(2906002)(316002)(70206006)(82740400003)(356005)(336012)(6486002)(47076004)(81166007)(70586007)(2616005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2020 22:05:52.5442 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4e67a4ba-3db7-4182-f50e-08d88c0e1d93 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6193 Archived-At: Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 22:06:11 -0000 We will take on board the majority of these comments. WRT the PQC time horizon, quantum annealing attacks on RSA are dependent co= mmercial quantum annealers. The paper in nature shows the factorisation of 376,289 in 94 qubits. In fac= t, other researchers have factored 1,005,973 with only 89 qubits [1]. With = this second algorithm, characterised as O(log^2(N)), RSA-768 would require = 147,454 qubits. D-Wave has shipped quantum computers with 5640 qubits alrea= dy. They have a historical average of doubling the number of qubits every t= wo years. Based on this trajectory, they should be shipping a quantum compu= ter that can break RSA-768 in approximately 2030 (log_2(147454/5640)) =3D 4= .7 =3D> 9.4 years. RSA-2048, then, would be broken between 2 and 4 years la= ter, and RSA-4096 a mere 2 years after that. This is a naive analysis. However, it is intended to show that a scalable g= eneral purpose quantum computer is not the only threat to current cryptogra= phic techniques, that the time horizon is not long, and that urgent action = is required to ensure that devices with long lifetimes account for EITHER c= ryptographic agility or quantum safety, preferably the latter, since quantu= m safe algorithms require much more data than classical asymmetric crypto a= nd, therefore, require extra considerations, particularly when used in cons= trained IoT. Obviously, the hole in this analysis is that RSA is not common in IoT. I ha= ve not yet found equivalent research that shows how a quantum annealer coul= d attack ECDSA or EDDSA. I assume that there are research teams working on = this. We should prepare ourselves for the potential of that particular reve= lation. We have not gone into this detail in the architecture because it seems both= orthogonal to the general discussion in the architecture, extremely time-s= ensitive, and extremely algorithm-sensitive. It will be an irrelevant predi= ction and analysis within a handful of years. Best Regards, Brendan [1] https://link.springer.com/article/10.1007/s11433-018-9307-1 > On 5 Nov 2020, at 09:38, Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-suit-architecture-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Does the XIP case mean that repeated firmware updates would have > potential to cause undue wear on the fixed flash cells that hold the > firmware image? If so, this might be noted in the security > considerations. > > I am not sure that I have fully digested Bob Briscoe's detailed review > comments, but it seems like we may want to continue to reflect on which > portions of the architecture will be optional to implement, and how we > might indicate that in the document. > > I also made a pull request for some editorial nits at > https://github.com/suit-wg/architecture/pull/15 . > > Section 1 > > otherwise difficult. Firmware updates > for IoT devices are expected to work automatically, i.e. without user > involvement. Conversely, IoT devices are expected to account for > user preferences and consent when scheduling updates. Automatic > > I can't quite tell if the "Conversely" case is intending to refer to IoT > or non-IoT devices. > > The firmware update process has to ensure that > > - The firmware image is authenticated and integrity protected. > [...] > > - The firmware image can be confidentiality protected so that > attempts by an adversary to recover the plaintext binary can be > [...] > > Perhaps it's just because Bob Briscoe's comments are fresh in my mind, > but there seems to be something of a mismatch across these texts -- we > "have to ensure" that the firmware *is* authenticated and integrity > protected, but only that the image *can be* confidentiality protected. > Is it really the case that we can ensure that an update process *can be* > confidentiality protected, or is the confidentiality requirement more of > a requirement on the architecture than on actual deployment? > > While the IETF standardization work has been focused on the manifest > format, a fully interoperable solution needs more than a standardized > manifest. For example, protocols for transferring firmware images > and manifests to the device need to be available as well as the > status tracker functionality. Devices also require a mechanism to > discover the status tracker(s) and/or firmware servers, for example > using pre-configured hostnames or [RFC6763] DNS-SD. These building > blocks have been developed by various organizations under the > umbrella of an IoT device management solution. The LwM2M protocol is > one IoT device management protocol. > > We might put some forward references to things we do cover (like status > tracker(s)), and a reference for LwM2M as well. > > Section 3 > > Hence, the following components are necessary on a device for a > firmware update solution: > [...] > - a status tracker. > > Earlier we said that having the status tracker on the device was fairly > uncommon. > > Section 7 > > time horizon for quantum-accelerated key extraction. The worst-case > estimate, at time of writing, for the time horizon to key extraction > with quantum acceleration is approximately 2030, based on current > research [quantum-factorization]. > > I'm not sure that I see how the reference suports the "approximately > 2030" statement. > > > IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Nov 18 16:34:17 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 054E33A1033; Wed, 18 Nov 2020 16:34:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: last-call@ietf.org, draft-ietf-suit-information-model.all@ietf.org, suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160574605497.24260.13971208595707468000@ietfa.amsl.com> Reply-To: Derrell Piper Date: Wed, 18 Nov 2020 16:34:15 -0800 Archived-At: Subject: [Suit] Secdir last call review of draft-ietf-suit-information-model-08 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 00:34:15 -0000 Reviewer: Derrell Piper Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Not Ready Caveat: I found this document difficult. I've not previously encountered an "Informational Model" like this one, and I have not been following IoT. If these comments sound completely unhelpful then I may just not be the right person to review this informational model. I would prefer MAY, MUST, or SHOULD be used consistently instead of OPTIONAL and RECOMMENDED. Both are used here. The draft is split into five lists, with 10 pages of Manifest Information Element descriptions presumably forming the basis of the draft, but followed by the bulk of the document as the Security Consideratios section. I found the organization confusing, too abstract, and somewhat circular. In summary: o manifest elements satisfy one or more requirements o threats are mitigated by one or more requirements o security requirements (REQ.SEC) mitigate one or more threats o user stories are satisfied by one or more usability requirements o usability requirements (REQ.USE) satisfy user stories pp.7 "the DNS name space ID" This implies private DNS namespace may be a concern, and I'd like to understand why and how, because this is based on Trust Anchors as described in RFC6024. What other DNS namespaces are under consideration? pp.17, "This model uses the S.T.R.I.D.E. approach" Microsoft's STRIDE Threat Model defines six types of threats: identity spoofing, data tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Why call out this particular approach? There may be traffic analysis and fingerprinting concerns if the manifest is not encrypted, specifically if the vendor IDs are sent unencrypted. pp.10, "...that version MUST be specified" It MUST be specified IF, but the element is OPTIONAL? pp.10 Manifest Element: Expiration Time Time is mentioned but no time format is specified. Is synchronized time a security requirement, and should specific time formats be specified? pp.32 4.4.3, "Satisfied by USER_STORY.OVERRIDE (Section 4.4.3)" Section 4.4.3 is circular (satisfies itself) Derrell From nobody Thu Nov 19 03:10:44 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B343A0825; Thu, 19 Nov 2020 03:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usP9HWBDMDja; Thu, 19 Nov 2020 03:10:37 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368593A0822; Thu, 19 Nov 2020 03:10:35 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AJBAP8Q010733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 06:10:29 -0500 Date: Thu, 19 Nov 2020 03:10:24 -0800 From: Benjamin Kaduk To: Brendan Moran Cc: The IESG , "draft-ietf-suit-architecture@ietf.org" , "suit-chairs@ietf.org" , suit , Russ Housley Message-ID: <20201119111024.GD39170@kduck.mit.edu> References: <160456913386.24093.10722400425795162498@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 11:10:39 -0000 Hi Brendan, Thanks for the extra reference and discussion about the timescale estimates for quantum computers and integer factorization. (And for accepting most of my other comments.) I see now how the factorization-by-annealing reference was intended to be used, and had not been paying close enough attention to know the 5640-qbit and doubling-every-two-years numbers for D-Wave. If I was going to suggest a change to the text, it would be quite small, perhaps something like "based on current research [quantum-factorization] and the trend in quantum annealing capacity". Thanks again, Ben On Wed, Nov 18, 2020 at 10:05:44PM +0000, Brendan Moran wrote: > We will take on board the majority of these comments. > > WRT the PQC time horizon, quantum annealing attacks on RSA are dependent commercial quantum annealers. > > The paper in nature shows the factorisation of 376,289 in 94 qubits. In fact, other researchers have factored 1,005,973 with only 89 qubits [1]. With this second algorithm, characterised as O(log^2(N)), RSA-768 would require 147,454 qubits. D-Wave has shipped quantum computers with 5640 qubits already. They have a historical average of doubling the number of qubits every two years. Based on this trajectory, they should be shipping a quantum computer that can break RSA-768 in approximately 2030 (log_2(147454/5640)) = 4.7 => 9.4 years. RSA-2048, then, would be broken between 2 and 4 years later, and RSA-4096 a mere 2 years after that. > > This is a naive analysis. However, it is intended to show that a scalable general purpose quantum computer is not the only threat to current cryptographic techniques, that the time horizon is not long, and that urgent action is required to ensure that devices with long lifetimes account for EITHER cryptographic agility or quantum safety, preferably the latter, since quantum safe algorithms require much more data than classical asymmetric crypto and, therefore, require extra considerations, particularly when used in constrained IoT. > > Obviously, the hole in this analysis is that RSA is not common in IoT. I have not yet found equivalent research that shows how a quantum annealer could attack ECDSA or EDDSA. I assume that there are research teams working on this. We should prepare ourselves for the potential of that particular revelation. > > We have not gone into this detail in the architecture because it seems both orthogonal to the general discussion in the architecture, extremely time-sensitive, and extremely algorithm-sensitive. It will be an irrelevant prediction and analysis within a handful of years. > > Best Regards, > Brendan > > [1] https://link.springer.com/article/10.1007/s11433-018-9307-1 > > > > On 5 Nov 2020, at 09:38, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-suit-architecture-14: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Does the XIP case mean that repeated firmware updates would have > > potential to cause undue wear on the fixed flash cells that hold the > > firmware image? If so, this might be noted in the security > > considerations. > > > > I am not sure that I have fully digested Bob Briscoe's detailed review > > comments, but it seems like we may want to continue to reflect on which > > portions of the architecture will be optional to implement, and how we > > might indicate that in the document. > > > > I also made a pull request for some editorial nits at > > https://github.com/suit-wg/architecture/pull/15 . > > > > Section 1 > > > > otherwise difficult. Firmware updates > > for IoT devices are expected to work automatically, i.e. without user > > involvement. Conversely, IoT devices are expected to account for > > user preferences and consent when scheduling updates. Automatic > > > > I can't quite tell if the "Conversely" case is intending to refer to IoT > > or non-IoT devices. > > > > The firmware update process has to ensure that > > > > - The firmware image is authenticated and integrity protected. > > [...] > > > > - The firmware image can be confidentiality protected so that > > attempts by an adversary to recover the plaintext binary can be > > [...] > > > > Perhaps it's just because Bob Briscoe's comments are fresh in my mind, > > but there seems to be something of a mismatch across these texts -- we > > "have to ensure" that the firmware *is* authenticated and integrity > > protected, but only that the image *can be* confidentiality protected. > > Is it really the case that we can ensure that an update process *can be* > > confidentiality protected, or is the confidentiality requirement more of > > a requirement on the architecture than on actual deployment? > > > > While the IETF standardization work has been focused on the manifest > > format, a fully interoperable solution needs more than a standardized > > manifest. For example, protocols for transferring firmware images > > and manifests to the device need to be available as well as the > > status tracker functionality. Devices also require a mechanism to > > discover the status tracker(s) and/or firmware servers, for example > > using pre-configured hostnames or [RFC6763] DNS-SD. These building > > blocks have been developed by various organizations under the > > umbrella of an IoT device management solution. The LwM2M protocol is > > one IoT device management protocol. > > > > We might put some forward references to things we do cover (like status > > tracker(s)), and a reference for LwM2M as well. > > > > Section 3 > > > > Hence, the following components are necessary on a device for a > > firmware update solution: > > [...] > > - a status tracker. > > > > Earlier we said that having the status tracker on the device was fairly > > uncommon. > > > > Section 7 > > > > time horizon for quantum-accelerated key extraction. The worst-case > > estimate, at time of writing, for the time horizon to key extraction > > with quantum acceleration is approximately 2030, based on current > > research [quantum-factorization]. > > > > I'm not sure that I see how the reference suports the "approximately > > 2030" statement. > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From nobody Thu Nov 19 07:08:57 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C305D3A09A8; Thu, 19 Nov 2020 07:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=N+YRUHYC; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=N+YRUHYC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je_twR6LmmjY; Thu, 19 Nov 2020 07:08:45 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30056.outbound.protection.outlook.com [40.107.3.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F3C3A09C4; Thu, 19 Nov 2020 07:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6VTXT+GVUdiy9zJ2mOA5YU4eAwPNbvZFH9VzAU/ko8M=; b=N+YRUHYCWEyr+xFqWHU5rqA11k2nGN2zKgV5DnaWFS/HtcP8zX6c12Q135pFn155glxwOseoO7btw1LckFo8z7Hdo29x6Am6gvqqpSes+Tgi8dRBdjSeKkfhGFKfIyzSxiGrpOo+TAoW99UWUlLDlhiZ0QJhYZJILymtjXT52fo= Received: from DB6P195CA0021.EURP195.PROD.OUTLOOK.COM (2603:10a6:4:cb::31) by VI1PR0801MB2061.eurprd08.prod.outlook.com (2603:10a6:800:8e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Thu, 19 Nov 2020 15:08:38 +0000 Received: from DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:cb:cafe::30) by DB6P195CA0021.outlook.office365.com (2603:10a6:4:cb::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Thu, 19 Nov 2020 15:08:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT049.mail.protection.outlook.com (10.152.20.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Thu, 19 Nov 2020 15:08:38 +0000 Received: ("Tessian outbound fcd5bc555ddc:v71"); Thu, 19 Nov 2020 15:08:38 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: e68948a0b505df4d X-CR-MTA-TID: 64aa7808 Received: from 903bdaf8dd7b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6B2B8915-A5C4-4C36-90E8-D1D16A1B8A1D.1; Thu, 19 Nov 2020 15:08:20 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 903bdaf8dd7b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 19 Nov 2020 15:08:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XMi9UoDz3qP2uItEDekHutWz9voGyoYtASNZ1ur7kN+Fxok/U6gFxSQdEbti5/ockARNYzgzaLz6h6lVxb+cGc+RiTpSMQE9EcfeHlQmv4JfyPkMbuGCm0LFHVMzaKya1Zugd/2RFUrtFl57X0lSqMWJJIk2HU/oTCsNKOX7f2DS2njiB7VzjoyVsz9yOZvCWPbkGNSI9GL6tuKhNULp75f10c/J2WU09SJVKJmxnsd+yLjXwlz50z6BNjc4BgvjEnN+tcITmG5lJn38pR8zdYGLNzGsF0JZgWhuvpBS1Aj5xFZBhvV0sDBOeniBqnrIDuwkMS3p08NPoRIeDvAjGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6VTXT+GVUdiy9zJ2mOA5YU4eAwPNbvZFH9VzAU/ko8M=; b=QqHVSJeUiS2k/Vu7ivoszrhWt6s+NZXH6z83/xX0U5RMTw8d47pD4xNrXaVClabe6QAAq9bjd0AnsPD0cxUGwZUs2D5J87ddieHYEDe2W+2zi+RC7f9e1oYA2TjAo/05sql+U+g6ciYx2/Dce3Om6px3yo/IUXdsycTNoIH/FmMAC14Yxsq5GnsFoJVtCqG1/U8zPDexVzgeRin3t+FnTftdofRovyNEgDRw2S96SnUcq0o2e2d3sTZJkBFlGstxhTW2gOa+zEX5rXnejy1uWawvrgOnXLacAULuFFrX4gkS7IPH4D/4gsutJjFp6sqizwqxGSQr+KftGviRs1lBaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6VTXT+GVUdiy9zJ2mOA5YU4eAwPNbvZFH9VzAU/ko8M=; b=N+YRUHYCWEyr+xFqWHU5rqA11k2nGN2zKgV5DnaWFS/HtcP8zX6c12Q135pFn155glxwOseoO7btw1LckFo8z7Hdo29x6Am6gvqqpSes+Tgi8dRBdjSeKkfhGFKfIyzSxiGrpOo+TAoW99UWUlLDlhiZ0QJhYZJILymtjXT52fo= Received: from AM9PR08MB6146.eurprd08.prod.outlook.com (2603:10a6:20b:2db::17) by AM9PR08MB6163.eurprd08.prod.outlook.com (2603:10a6:20b:2de::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Thu, 19 Nov 2020 15:08:19 +0000 Received: from AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5]) by AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5%4]) with mapi id 15.20.3589.021; Thu, 19 Nov 2020 15:08:19 +0000 From: Brendan Moran To: Derrell Piper CC: "secdir@ietf.org" , "draft-ietf-suit-information-model.all@ietf.org" , "last-call@ietf.org" , "suit@ietf.org" Thread-Topic: [Suit] Secdir last call review of draft-ietf-suit-information-model-08 Thread-Index: AQHWvgvPhlBbsjTKVUWq+88B5DBW36nPj4mA Date: Thu, 19 Nov 2020 15:08:19 +0000 Message-ID: <7BD14CD2-1CD2-4307-966E-637211539F6B@arm.com> References: <160574605497.24260.13971208595707468000@ietfa.amsl.com> In-Reply-To: <160574605497.24260.13971208595707468000@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) Authentication-Results-Original: electric-loft.org; dkim=none (message not signed) header.d=none;electric-loft.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.7.184.196] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 310d9537-b12f-4fa1-80f0-08d88c9cfe6e x-ms-traffictypediagnostic: AM9PR08MB6163:|VI1PR0801MB2061: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: jGuIDJqRvoTAyXFNIsZUpLR9tlgaIs65LxXppgmeFgU7TKMVybTaHQAAr558KqAHjervXFXjz9eE8YsQ07xOQ7bgpKwxpg0UNdKPoHcOAxqSwkSH/MpkDco2zLY6NGtQWlnDVL0TgKUe2lCBMs7L1dXUtv7GsgXZ6q5TGUHt6jmqUcJBcA5FtJu+skF/5UWgptIwPG8a7Ku2PRKoRTW+6HHCbQheYmtgkGpDprj/wNwpSwDDjINSUUJ10+i5Ib6/uOavVbWCsIb+yJ9ri+y8XNTqNezteHnS1bsxT0RezpJWnfMT7nrQV0J667/0FitDov95XjQ022BNTwOVbKc5G4ONJbJevfrfPPzV3VjuMmH9OSLD6mtZjCMRQJr+SDxqoP8dBpcLOBXDt5tdk8DkSw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR08MB6146.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(6486002)(86362001)(8676002)(53546011)(8936002)(26005)(6506007)(6512007)(6916009)(36756003)(478600001)(83380400001)(5660300002)(66446008)(54906003)(316002)(966005)(45080400002)(2906002)(91956017)(186003)(64756008)(4326008)(71200400001)(2616005)(66556008)(33656002)(66476007)(66946007)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: byoVf+Ij9t+5mLfVS6q6IiWJv34HdaG7mbSmDL1NSFpeyEZyOpkk+JW2L1QXnSxfD7Lnyrj762SkfDqXfuuPYtecU5lHsTZjeYjxETJZc06wTH6aYo7a6x2KPZr2DhLS1yg8CzqURZVCz3CKKCzx6zGqCUPSfnREkTxqAW4y7IXhQk7gOddLnQY7jsoIBXQQvzIfz7x4/EcZZFiahmVh2DEm70YNfrlkfjnWIImO1n5I9XBdopmAEqGEsf2GGAoHG1Y3f8N5QKp4xVSW1QjvqAg8HipkDCFeqwwHTX9cYV9p+kfycJEPW3JpCLHd+MVfndg1iz8IbQd1YzLzH0TY64gRyy2J19qTd9nxnSwuCV8Ha1qVl35BTjOi3VEB3mXas0gnTWipqUFuKzYamGjIamS6ZWGs0ieJ0Jm3E5870XWebxqiyn4jz8w2Z6v0k01JBSTJvQfvzlJZHsxM+zxmyS0jz1d97q+7l+u7a/ISQoPhSaAq3891C0nie8aEmymGdtDI8n97VH6qzVWnm0Yao4d1DgmWJzhiOHJ9WQfTv/5JeR9hP+h8lwWTVq05Nq6vF4xnSkGdXwf5YuRG1cen9DkwQFX9qXTOMTOJj0g/xaum+9dPfnhBie+D+nEv03zH5KfJ//L1nYpvdk1XowQL4VCMX0iTmeGkwc8O/KgZZY5rifcLS9fc/ZDaEFBooMrdZ9C+mxKGZyuO30Z+MdU1KFY9YGoNnX3gHPrAucxi0Zbet97a4ltSyV3H8AYpZdYN1KH1sRy8FP+5ALPGV1gV2Ys+oBy7A5yIuvwayzUBhnDNQJ371QBAxrLU27ebgv1wPdmPHMJ/XYXadNae0zcqQ38Pp2gYnjUMOrZ65wew9irgPUFTCuToZDtqUoSqdTlvS6lFEuXUEXvmACfEGb9Q2Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9F06C4779E040F43ABB9565811D48B88@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6163 Original-Authentication-Results: electric-loft.org; dkim=none (message not signed) header.d=none;electric-loft.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 39b5443e-5691-485e-a4b2-08d88c9cf355 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IFpyQyR5qIpgqxi3WDtK5+24LoZAO0KbXKvofcCYzn92y3rpwyhQJxhFt7SMcoZKlaPpshnaFXtsJPOw5X9jhG3D36/YHTJX1WriWf54rx0MUk1CIyFhFBKvb0GHk/g7cyiBtzMV5zNYZqZXYj7qV0mDwXDcOBLWPRS7oZdKg4PBYQNZJ486/Z23v/iurPGtOpxxEHqkf5/5+luC9BuuA3dfhFdqVY5O6aNpr1+420MFWbNoPQDqbclG0jtB7iTnObR+5BwBjOmvfCywaQVN/RBIQl97kYvdt3S2tilrphfOpcHjLm/C7cA7x4bEcNTnVxOgqFy1CDAG7aw5rBpZJ1NjIrE+Raeasv3D3zAC+yflQlqNFGmJc0aXTp//ltXaqstM/dYqU09JYgyspCjO29LW8l7Um+TaZIV62o9VEa4z+pgBG1quTqxVvZt5ApHr9IH1Euou07X4XbohgafYdulFK7kabahwPHrotHczlSg= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(39850400004)(396003)(346002)(376002)(46966005)(316002)(478600001)(26005)(70206006)(2906002)(83380400001)(6486002)(186003)(82740400003)(8936002)(4326008)(356005)(336012)(54906003)(36756003)(47076004)(966005)(450100002)(81166007)(6862004)(70586007)(8676002)(86362001)(33656002)(5660300002)(6506007)(82310400003)(53546011)(2616005)(6512007)(45080400002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2020 15:08:38.4216 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 310d9537-b12f-4fa1-80f0-08d88c9cfe6e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2061 Archived-At: Subject: Re: [Suit] Secdir last call review of draft-ietf-suit-information-model-08 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:08:48 -0000 SGkgRGVycmVsbCwNCg0KSXQgc2VlbXMgbGlrZSB3ZeKAmXJlIGNvbWluZyBhdCB0aGlzIGZyb20g dmVyeSBkaWZmZXJlbnQgYW5nbGVzLCBzbyBsZXQgbWUgdHJ5IHRvIHNldCBzb21lIGNvbnRleHQu IFRoZSBTVUlUIG1hbmlmZXN0LCB3aGljaCBpcyB0aGUgZmlyc3Qgbm9ybWF0aXZlIHNwZWNpZmlj YXRpb24gZXhwZWN0ZWQgZnJvbSB0aGUgU1VJVCBXRywgaXMgYSBkb2N1bWVudCBmb3JtYXQgdGhh dCBkZWZpbmVzIGEgcHJvY2VzcyBmb3IgYSBkZXZpY2UgdG8gcHJvZ3Jlc3MgZnJvbSBvbmUgdmVy c2lvbiBvZiBvbmUgb3IgbW9yZSBmaXJtd2FyZS9zb2Z0d2FyZS9kYXRhIGNvbXBvbmVudHMgdG8g YW5vdGhlciB2ZXJzaW9uIG9mIHRoYXQvdGhvc2UgY29tcG9uZW50cy4gQSBtYW5pZmVzdCBtYXkg YWxzbyBkZWZpbmUgYSBwcm9jZXNzIGZvciBhIGRldmljZSB0byBkZXRlcm1pbmUgd2hldGhlciBv ciBub3QgaXQgaGFzIGFsbCByZXF1aXJlZCBjb21wb25lbnRzLCB0aGF0IHRoZXkgYXJlIGNvcnJl Y3QsIGxvYWQgdGhvc2UgY29tcG9uZW50cyBpbnRvIGV4ZWN1dGFibGUgbWVtb3J5IGlmIG5lZWRl ZCwgYW5kIHRoZW4gaW52b2tlIG9uZSBvciBtb3JlIGNvbXBvbmVudHMuDQoNClVwZGF0aW5nIHRo ZSBjb21wb25lbnRzIG9mIGEgZGV2aWNlLCBpcyBhIHNlY3VyaXR5IHNlbnNpdGl2ZSBwcm9jZXNz IHRoYXQgaXMsIGJ5IGl0cyB2ZXJ5IGRlZmluaXRpb24sIHJlbW90ZSBjb2RlIGV4ZWN1dGlvbi4g VGh1cywgd2hpbGUgZmlybXdhcmUgdXBkYXRlIG1lY2hhbmlzbXMgYXJlIHRoZSBzaW5nbGUgbW9z dCBpbXBvcnRhbnQgc2VjdXJpdHkgdG9vbCB3ZSBoYXZlIGZvciBwYXRjaGluZyB2dWxuZXJhYmls aXRpZXMsIHRoZXkgYXJlIGFsc28gdGhlIHNpbmdsZSBtb3N0IGRhbmdlcm91cyB0b29sOiBhbnkg ZmxhdyBpbiBhbiB1cGRhdGUgbWVjaGFuaXNtIGNvdWxkIGxlYWQgdG8gY29tcGxldGUgbWFsaWNp b3VzIHRha2VvdmVyIG9mIGEgZGV2aWNlLiBBcyBhIHJlc3VsdCwgd2UgaGF2ZSB0YWtlbiBhIHZl cnkgcGFydGljdWxhciBhcHByb2FjaCB0byB0aGUgSW5mb3JtYXRpb24gbW9kZWwuDQoNCkl0IHNo b3VsZCBiZSBzYWlkIHRoYXQgdGhlIEluZm9ybWF0aW9uIE1vZGVsIHdhcyBvcmlnaW5hbGx5IGRl ZmluZWQgYXMgYSBUaHJlYXQgTW9kZWwgd2l0aGluIHRoZSBhcmNoaXRlY3R1cmUsIGJ1dCBpdCB3 YXMgbGF0ZXIgc2VwYXJhdGVkIGZyb20gdGhlIGFyY2hpdGVjdHVyZSBhbmQgZ3JvdXBlZCB3aXRo IGEgbGlzdCBvZiByZXF1aXJlZCBpbmZvcm1hdGlvbiwgcmVzdWx0aW5nIGluIHRoZSBpbmZvcm1h dGlvbiBtb2RlbCBhcyBpdCBpcyB0b2RheS4gSXQgd291bGQgcHJvYmFibHkgYmUgbW9yZSBwcmVj aXNlIHRvIGRlZmluZSB0aGUgZG9jdW1lbnQgYXMgYSDigJxTZWN1cml0eSBhbmQgVXNhYmlsaXR5 IG1vZGVsLuKAnSBNYXliZSB3ZSBzaG91bGQgY2FsbCBpdCBhbiDigJxpbmZvcm1hdGlvbiBhbmQg dGhyZWF0IG1vZGVsLiINCg0KUGxlYXNlIHNlZSBmdXJ0aGVyIGNvbW1lbnRzIGlubGluZS4NCg0K QmVzdCBSZWdhcmRzLA0KQnJlbmRhbg0KDQo+IE9uIDE5IE5vdiAyMDIwLCBhdCAwMDozNCwgRGVy cmVsbCBQaXBlciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPg0K PiBSZXZpZXdlcjogRGVycmVsbCBQaXBlcg0KPiBSZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHkNCj4N Cj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkg ZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1l bnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQo+IGNvbW1lbnRzIHdlcmUg d3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhDQo+ IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg dGhlc2UgY29tbWVudHMganVzdA0KPiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMu DQo+DQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IE5vdCBSZWFkeQ0KPg0KPiBDYXZl YXQ6IEkgZm91bmQgdGhpcyBkb2N1bWVudCBkaWZmaWN1bHQuICBJJ3ZlIG5vdCBwcmV2aW91c2x5 IGVuY291bnRlcmVkIGFuDQo+ICJJbmZvcm1hdGlvbmFsIE1vZGVsIiBsaWtlIHRoaXMgb25lLCBh bmQgSSBoYXZlIG5vdCBiZWVuIGZvbGxvd2luZyBJb1QuICBJZg0KPiB0aGVzZSBjb21tZW50cyBz b3VuZCBjb21wbGV0ZWx5IHVuaGVscGZ1bCB0aGVuIEkgbWF5IGp1c3Qgbm90IGJlIHRoZSByaWdo dA0KPiBwZXJzb24gdG8gcmV2aWV3IHRoaXMgaW5mb3JtYXRpb25hbCBtb2RlbC4NCg0KV2UgYmVs aWV2ZSB0aGF0IGl0IGlzIG5lY2Vzc2FyeSB0byBqdXN0aWZ5IHRoZSBwcmVzZW5jZSBvZiBlYWNo IGluZm9ybWF0aW9uIGVsZW1lbnQuIFRoaXMgcmVxdWlyZXMgZGVmaW5pbmcgZXhhY3RseSB3aGlj aCBzZWN1cml0eSByZXF1aXJlbWVudHMgYW5kIHVzYWJpbGl0eSByZXF1aXJlbWVudHMgZ2l2ZSBy aXNlIHRvIGVhY2ggaW5mb3JtYXRpb24gZWxlbWVudC4gU2ltaWxhcmx5IHNlY3VyaXR5IHJlcXVp cmVtZW50cyBhbmQgdXNhYmlsaXR5IHJlcXVpcmVtZW50cyBkbyBub3QgZXhpc3QgaW4gYSB2YWN1 dW0uIFNlY3VyaXR5IHJlcXVpcmVtZW50cyB0aGF0IGRvIG5vdCBtaXRpZ2F0ZSB0aHJlYXRzIGFu ZCB1c2FiaWxpdHkgcmVxdWlyZW1lbnRzIHRoYXQgZG8gbm90IGVuYWJsZSB1c2VyIHN0b3JpZXMg YXJlIG5lZWRsZXNzIGNvbXBsZXhpdHkuIEluc3RlYWQgb2YgbGVhdmluZyB0aGVzZSBpbXBsaWNp dCwgYXMgaXMgZG9uZSBpbiBtYW55IGRvY3VtZW50cywgd2UgaGF2ZSBmdWxseSBkZWZpbmVkIHRo ZW0uDQoNClRoaXMgZG9lcyBtYWtlIHRoZSBkb2N1bWVudCBzb21ld2hhdCBkaWZmZXJlbnQgZnJv bSBvdGhlciBpbmZvcm1hdGlvbiBtb2RlbHMsIGJ1dCB3ZSBiZWxpZXZlIHRoYXQgdGhvc2Ugd2hv IHJlYWQgdGhlIGluZm9ybWF0aW9uIG1vZGVsIHNob3VsZCB1bmRlcnN0YW5kIHRoZSBwdXJwb3Nl IG9mIGVhY2ggZWxlbWVudCBhbmQgdGhhdCB0aGUgb25seSB3YXkgdGhhdCB0aGV5IGNhbiB1bmRl cnN0YW5kIHRob3NlIHB1cnBvc2VzIGlzIHRvIHNlZSB3aHkgdGhlIGVsZW1lbnRzIGFyZSB0aGVy ZS4NCg0KPiBJIHdvdWxkIHByZWZlciBNQVksIE1VU1QsIG9yIFNIT1VMRCBiZSB1c2VkIGNvbnNp c3RlbnRseSBpbnN0ZWFkIG9mIE9QVElPTkFMDQo+IGFuZCBSRUNPTU1FTkRFRC4gIEJvdGggYXJl IHVzZWQgaGVyZS4NCg0KV2UgaGF2ZSBjaG9zZW4gdGVybXMgYmFzZWQgb24gaG93IHRoZXkgYmVz dCBmaXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgc3Vycm91bmRpbmcgZ3JhbW1hci4gSWYgd2UgbmVl ZCB0byBjaG9vc2Ugb25lIHNldCBvZiB0ZXJtaW5vbG9neSwgd2UgY2FuIGRvIHRoaXMsIGJ1dCBp dCB3aWxsIHJlcXVpcmUgc3Vic3RhbnRpYWwgcmVwaHJhc2luZy4gQkNQMTQgZG9lcyBub3QgZ2l2 ZSBndWlkYW5jZSBvbiB1c2luZyBvbmx5IG9uZSBvZiAoTUFZLE9QVElPTkFMKSBvciAoU0hPVUxE LFJFQ09NTUVOREVEKSBjb25zaXN0ZW50bHkuIElzIHRoZXJlIGEgcmVmZXJlbmNlIHRoYXQgZ2l2 ZXMgZ3VpZGFuY2Ugb24gdGhpcyB0b3BpYz8NCg0KPiBUaGUgZHJhZnQgaXMgc3BsaXQgaW50byBm aXZlIGxpc3RzLCB3aXRoIDEwIHBhZ2VzIG9mIE1hbmlmZXN0IEluZm9ybWF0aW9uDQo+IEVsZW1l bnQgZGVzY3JpcHRpb25zIHByZXN1bWFibHkgZm9ybWluZyB0aGUgYmFzaXMgb2YgdGhlIGRyYWZ0 LCBidXQgZm9sbG93ZWQNCj4gYnkgdGhlIGJ1bGsgb2YgdGhlIGRvY3VtZW50IGFzIHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9zIHNlY3Rpb24uICBJIGZvdW5kDQo+IHRoZSBvcmdhbml6YXRpb24g Y29uZnVzaW5nLCB0b28gYWJzdHJhY3QsIGFuZCBzb21ld2hhdCBjaXJjdWxhci4gIEluIHN1bW1h cnk6DQo+DQo+ICBvIG1hbmlmZXN0IGVsZW1lbnRzIHNhdGlzZnkgb25lIG9yIG1vcmUgcmVxdWly ZW1lbnRzDQo+ICBvIHRocmVhdHMgYXJlIG1pdGlnYXRlZCBieSBvbmUgb3IgbW9yZSByZXF1aXJl bWVudHMNCj4gIG8gc2VjdXJpdHkgcmVxdWlyZW1lbnRzIChSRVEuU0VDKSBtaXRpZ2F0ZSBvbmUg b3IgbW9yZSB0aHJlYXRzDQo+ICBvIHVzZXIgc3RvcmllcyBhcmUgc2F0aXNmaWVkIGJ5IG9uZSBv ciBtb3JlIHVzYWJpbGl0eSByZXF1aXJlbWVudHMNCj4gIG8gdXNhYmlsaXR5IHJlcXVpcmVtZW50 cyAoUkVRLlVTRSkgc2F0aXNmeSB1c2VyIHN0b3JpZXMNCg0KV291bGQgeW91IGZpbmQgaXQgbGVz cyBjb25mdXNpbmcgdG8gb3JkZXIgaXQgYXMgZm9sbG93cz8NCg0KICBvIGVsZW1lbnRzDQogIG8g cmVxdWlyZW1lbnRzDQogIG8gdGhyZWF0cy91c2VyIHN0b3JpZXMNCg0KVGhlIHdvcmtpbmcgZ3Jv dXAgd2FzIHF1aXRlIGNsZWFyIHRoYXQgdGhlIGxpc3Qgb2YgaW5mb3JtYXRpb24gZWxlbWVudHMg c2hvdWxkIGNvbWUgZmlyc3QgYW5kIGJlIGp1c3RpZmllZCBieSBzdWJzZXF1ZW50IHNlY3Rpb25z Lg0KDQo+IHBwLjcgInRoZSBETlMgbmFtZSBzcGFjZSBJRCINCj4NCj4gVGhpcyBpbXBsaWVzIHBy aXZhdGUgRE5TIG5hbWVzcGFjZSBtYXkgYmUgYSBjb25jZXJuLCBhbmQgSSdkIGxpa2UgdG8NCj4g dW5kZXJzdGFuZCB3aHkgYW5kIGhvdywgYmVjYXVzZSB0aGlzIGlzIGJhc2VkIG9uIFRydXN0IEFu Y2hvcnMgYXMgZGVzY3JpYmVkIGluDQo+IFJGQzYwMjQuICBXaGF0IG90aGVyIEROUyBuYW1lc3Bh Y2VzIGFyZSB1bmRlciBjb25zaWRlcmF0aW9uPw0KDQpUaGlzIGlzIGFuIGV4cGxpY2l0IHJlZmVy ZW5jZXMgdG8gUkZDNDEyMi4gVGhlIGZ1bGwgc2VudGVuY2UgdW5kZXIgZGlzY3Vzc2lvbiByZWFk czoNCg0KPiAgICBSZWNvbW1lbmRlZCBwcmFjdGljZQ0KPiAgICBpcyB0byB1c2UgWw0KPiBSRkM0 MTIyDQo+IF0gdmVyc2lvbiA1IFVVSURzIHdpdGggdGhlIHZlbmRvcidzIGRvbWFpbiBuYW1lIGFu ZA0KPiAgICB0aGUgRE5TIG5hbWUgc3BhY2UgSUQuDQo+DQoNClJGQzQxMjIgc2F5cyAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxMjIjc2VjdGlvbi00LjMpOg0KDQo+ICAgICAgIEFs bG9jYXRlIGEgVVVJRCB0byB1c2UgYXMgYSAibmFtZSBzcGFjZSBJRCIgZm9yIGFsbCBVVUlEcw0K PiAgICAgICBnZW5lcmF0ZWQgZnJvbSBuYW1lcyBpbiB0aGF0IG5hbWUgc3BhY2U7IHNlZQ0KPiBB cHBlbmRpeCBDDQo+ICBmb3Igc29tZQ0KPiAgICAgICBwcmUtZGVmaW5lZCB2YWx1ZXMNCj4NCg0K QW5kIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDEyMiNhcHBlbmRpeC1DKToNCg0K PiAgICAvKiBOYW1lIHN0cmluZyBpcyBhIGZ1bGx5LXF1YWxpZmllZCBkb21haW4gbmFtZSAqLw0K PiAgICB1dWlkX3QgTmFtZVNwYWNlX0ROUyA9IHsgLyogNmJhN2I4MTAtOWRhZC0xMWQxLTgwYjQt MDBjMDRmZDQzMGM4ICovDQo+ICAgICAgICAweDZiYTdiODEwLA0KPiAgICAgICAgMHg5ZGFkLA0K PiAgICAgICAgMHgxMWQxLA0KPiAgICAgICAgMHg4MCwgMHhiNCwgMHgwMCwgMHhjMCwgMHg0Ziwg MHhkNCwgMHgzMCwgMHhjOA0KPiAgICB9Ow0KDQpUaGVyZWZvcmUsIHdoZW4gdGhlIHN1aXQtaW5m b3JtYXRpb24tbW9kZWwgcmVmZXJlbmNlcyDigJx0aGUgRE5TIG5hbWUgc3BhY2UgSUTigJ0gaXQg aXMgcmVmZXJyaW5nIHRvIHRoZSBVVUlEIGluIFJGQzQxMjIsIEFwcGVuZGl4LUM6DQoNCj4gNmJh N2I4MTAtOWRhZC0xMWQxLTgwYjQtMDBjMDRmZDQzMGM4DQoNCldvdWxkIGl0IGJlIGNsZWFyZXIg dG8gcmVwaHJhc2UgdGhlIG9yaWdpbmFsIHRleHQgYXMgZm9sbG93cz8NCg0KPiAgICBSZWNvbW1l bmRlZCBwcmFjdGljZQ0KPiAgICBpcyB0byB1c2UgWw0KPiBSRkM0MTIyDQo+IF0gdmVyc2lvbiA1 IFVVSURzIHdpdGggdGhlIHZlbmRvcidzIGRvbWFpbiBuYW1lIGFuZA0KPiAgICA2YmE3YjgxMC05 ZGFkLTExZDEtODBiNC0wMGMwNGZkNDMwYzggKHRoZSBETlMgbmFtZSBzcGFjZSBJRCkuDQo+DQoN CkFzIGl0IGhhcHBlbnMsIHRoZSBTVUlUIHdvcmtpbmcgZ3JvdXAgaGFzIGRpc2N1c3NlZCB0aGUg cG9zc2liaWxpdHkgb2YgdXNpbmcgUHJpdmF0ZSBFbnRlcnByaXNlIE51bWJlcnMgaW4gcGxhY2Ug b2YgVVVJRHMgZm9yIFZlbmRvciBJRHMgYXMgd2VsbC4gVGhpcyBhY3Rpb24gaXMgIHBlbmRpbmcg aW4gdGhlIHdvcmtpbmcgZ3JvdXAsIGFzIGFuIHVwZGF0ZSB0byB0aGUgbWFuaWZlc3Qgc3BlY2lm aWNhdGlvbi4NCg0KDQo+IHBwLjE3LCAiVGhpcyBtb2RlbCB1c2VzIHRoZSBTLlQuUi5JLkQuRS4g YXBwcm9hY2giDQo+DQo+IE1pY3Jvc29mdCdzIFNUUklERSBUaHJlYXQgTW9kZWwgZGVmaW5lcyBz aXggdHlwZXMgb2YgdGhyZWF0czogaWRlbnRpdHkNCj4gc3Bvb2ZpbmcsIGRhdGEgdGFtcGVyaW5n LCByZXB1ZGlhdGlvbiwgaW5mb3JtYXRpb24gZGlzY2xvc3VyZSwgZGVuaWFsIG9mDQo+IHNlcnZp Y2UsIGFuZCBlbGV2YXRpb24gb2YgcHJpdmlsZWdlLiAgV2h5IGNhbGwgb3V0IHRoaXMgcGFydGlj dWxhciBhcHByb2FjaD8NCg0KU29tZSBtZXRob2RvbG9neSBtdXN0IGJlIHVzZWQgaW4gb3JkZXIg dG8gcGVyZm9ybSBhIHRocmVhdCBhbmFseXNpcy4gVGhpcyBpcyB0aGUgbWV0aG9kIHdlIHVzZWQg YW5kIGl0IGRlZmluZXMgdGhlIHRlcm1pbm9sb2d5IHVzZWQgdG8gY2xhc3NpZnkgdGhlIHZhcmlv dXMgdGhyZWF0cyBpbiB0aGUgdGhyZWF0IG1vZGVsLiBJcyB0aGVyZSBhIHJlYXNvbiB0byByZW1v dmUgdGhpcyByZWZlcmVuY2UgZ2l2ZW4gdGhhdCBpdCBkZWZpbmVzIHRoZSB0ZXJtaW5vbG9neSB1 c2VkIGluIHRoZSB0aHJlYXQgbW9kZWw/DQoNCj4gVGhlcmUgbWF5IGJlIHRyYWZmaWMgYW5hbHlz aXMgYW5kIGZpbmdlcnByaW50aW5nIGNvbmNlcm5zIGlmIHRoZSBtYW5pZmVzdCBpcw0KPiBub3Qg ZW5jcnlwdGVkLCBzcGVjaWZpY2FsbHkgaWYgdGhlIHZlbmRvciBJRHMgYXJlIHNlbnQgdW5lbmNy eXB0ZWQuDQoNCkkgYmVsaWV2ZSB0aGlzIGlzIFRIUkVBVC5NRlNULkVYUE9TVVJFIGFuZC9vciBU SFJFQVQuTkVULk9OUEFUSC4gVGhlIG1pdGlnYXRpb24gaXM6IFJFUS5TRUMuTUZTVC5DT05GSURF TlRJQUxJVFk6IEVuY3J5cHRlZCBNYW5pZmVzdHMsIHdoaWNoIGlzIGltcGxlbWVudGVkIGJ5OiBF eHRlcm5hbCBFbmNyeXB0aW9uIFdyYXBwZXIgLyBUcmFuc3BvcnQgU2VjdXJpdHkNCg0KU2VlIHRo ZXNlIHNlY3Rpb25zIGZvciBmdWxsIGRldGFpbHM6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zdWl0LWluZm9ybWF0aW9uLW1vZGVsLTA4I3NlY3Rpb24tNC4yLjcNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXN1aXQtaW5mb3JtYXRpb24tbW9k ZWwtMDgjc2VjdGlvbi00LjIuMTQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXN1aXQtaW5mb3JtYXRpb24tbW9kZWwtMDgjc2VjdGlvbi00LjMuMTQNCg0KPiBwcC4xMCwg Ii4uLnRoYXQgdmVyc2lvbiBNVVNUIGJlIHNwZWNpZmllZCINCj4NCj4gSXQgTVVTVCBiZSBzcGVj aWZpZWQgSUYsIGJ1dCB0aGUgZWxlbWVudCBpcyBPUFRJT05BTD8NCg0KQ29ycmVjdC4gSXQgTVVT VCBiZSBzdXBwb3J0ZWQgYnkgdGhlIHNlcmlhbGl6YXRpb24sIGJ1dCBhIGdpdmVuIGRlcGxveW1l bnQgZG9lcyBub3QgcmVxdWlyZSBpdCBpZiwgZm9yIGV4YW1wbGUsIGl0IGRvZXMgbm90IHN1cHBv cnQgZGlmZmVyZW50aWFsIHVwZGF0ZXMuIFNvIGl0IGlzIFJFUVVJUkVEIGluIHRoZSBzZXJpYWxp emF0aW9uLCBidXQgT1BUSU9OQUwgdG8gaW1wbGVtZW50IGluIGFueSBnaXZlbiBtYW5pZmVzdCBv ciBtYW5pZmVzdCBwcm9jZXNzb3IuDQoNCj4gcHAuMTAgTWFuaWZlc3QgRWxlbWVudDogRXhwaXJh dGlvbiBUaW1lDQo+DQo+IFRpbWUgaXMgbWVudGlvbmVkIGJ1dCBubyB0aW1lIGZvcm1hdCBpcyBz cGVjaWZpZWQuICBJcyBzeW5jaHJvbml6ZWQgdGltZSBhDQo+IHNlY3VyaXR5IHJlcXVpcmVtZW50 LCBhbmQgc2hvdWxkIHNwZWNpZmljIHRpbWUgZm9ybWF0cyBiZSBzcGVjaWZpZWQ/DQoNCkluIGdl bmVyYWwsIHdlIHRyeSBub3QgdG8gcmVxdWlyZSBhIHN5bmNocm9uaXNlZCB0aW1lIHNvdXJjZSwg c2luY2UgdGhpcyBwdXRzIHN1YnN0YW50aWFsIHJlcXVpcmVtZW50cyBvbiBhIGNvbnN0cmFpbmVk IGRldmljZS4gWW91IGFyZSBjb3JyZWN0IHRoYXQsIGZvciBhbiBpbWFnZSB0byBleHBpcmUsIHNv bWUgbm90aW9uIG9mIHRpbWUgaXMgbmVjZXNzYXJ5LiBUaGlzIGNhbiBiZSBjb21wbGV4IG9yIHNp bXBsZS4gV2UgZG8gbm90IHJlcXVpcmUgbWlsbGlzZWNvbmQgYWNjdXJhY3k7IGV2ZW4gZGlzcGxh eWluZyDigJxUb2RheeKAmXMgRGF0ZeKAnSB0byBhIHVzZXIgd291bGQgYmUg4oCcc2VjdXJlIGVu b3VnaOKAnSBmb3IgdGhpcyB1c2Ugc2luY2UsIGFzIG5vdGVkIGluIHRoZSBkcmFmdDoNCg0KPiAg ICBUaGlzIGVsZW1lbnQgbWF5IGFsc28gYmUgZGlzcGxheWVkIChlLmcuIHZpYSBhbiBhcHApDQo+ ICAgIGZvciB1c2VyIGNvbmZpcm1hdGlvbiBzaW5jZSB1c2VycyB0eXBpY2FsbHkgaGF2ZSBhIHJl bGlhYmxlIGtub3dsZWRnZQ0KPiAgICBvZiB0aGUgZGF0ZS4NCj4NCg0KSXMgdGhlcmUgYSByZWFz b24gdG8gaW5jbHVkZSBzcGVjaWZpYyB0aW1lIGZvcm1hdHMgaW4gdGhlIGluZm9ybWF0aW9uIG1v ZGVsLCByYXRoZXIgdGhhbiBhIHNlcmlhbGl6YXRpb24gdGhlcmVvZj8NCg0KPiBwcC4zMiA0LjQu MywgIlNhdGlzZmllZCBieSBVU0VSX1NUT1JZLk9WRVJSSURFIChTZWN0aW9uIDQuNC4zKSINCj4N Cj4gU2VjdGlvbiA0LjQuMyBpcyBjaXJjdWxhciAoc2F0aXNmaWVzIGl0c2VsZikNCg0KVGhpcyBp cyBhIHJlZmVyZW5jZSBlcnJvci4gVGhhbmtzIGZvciBwaWNraW5nIGl0IHVwLiBUaGUgY29ycmVj dCByZWZlcmVuY2UgaXM6DQoNCjQuNS4yLiBSRVEuVVNFLk1GU1QuT1ZFUlJJREVfUkVNT1RFDQoN Cj4gRGVycmVsbA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBTdWl0IG1haWxpbmcgbGlzdA0KPiBTdWl0QGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VpdA0KDQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Thu Nov 19 11:57:45 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1363A10F9; Thu, 19 Nov 2020 11:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0X970sn0VDx; Thu, 19 Nov 2020 11:57:35 -0800 (PST) Received: from Mail1.Yoyodyne.COM (mail1.yoyodyne.com [IPv6:2604:4ec0:1000::7]) by ietfa.amsl.com (Postfix) with SMTP id 0D2C23A12D4; Thu, 19 Nov 2020 11:57:10 -0800 (PST) Received: from [192.168.1.83] ([24.5.60.91]) by Mail1.Yoyodyne.COM via Internet for (and others); Thu, 19 Nov 2020 11:56:32 PST To: Brendan Moran Cc: "secdir@ietf.org" , "draft-ietf-suit-information-model.all@ietf.org" , "last-call@ietf.org" , "suit@ietf.org" References: <160574605497.24260.13971208595707468000@ietfa.amsl.com> <7BD14CD2-1CD2-4307-966E-637211539F6B@arm.com> From: Derrell Piper Message-ID: Date: Thu, 19 Nov 2020 11:57:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <7BD14CD2-1CD2-4307-966E-637211539F6B@arm.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050003030705060505060508" Archived-At: Subject: Re: [Suit] Secdir last call review of draft-ietf-suit-information-model-08 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 19:57:38 -0000 This is a cryptographically signed message in MIME format. --------------ms050003030705060505060508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Brendon, On 11/19/2020 7:08 AM, Brendan Moran wrote: > It should be said that the Information Model was originally defined as = a Threat Model within the architecture, but it was later separated from t= he architecture and grouped with a list of required information, resultin= g in the information model as it is today. It would probably be more prec= ise to define the document as a =E2=80=9CSecurity and Usability model.=E2= =80=9D Maybe we should call it an =E2=80=9Cinformation and threat model."= I think that change would help. I almost wrote that I felt this=20 document should have been contained in another, so there you go. > We believe that it is necessary to justify the presence of each informa= tion element. This requires defining exactly which security requirements = and usability requirements give rise to each information element. Similar= ly security requirements and usability requirements do not exist in a vac= uum. Security requirements that do not mitigate threats and usability req= uirements that do not enable user stories are needless complexity. Instea= d of leaving these implicit, as is done in many documents, we have fully = defined them. Absolutely no need to apologize for considering usability. > This does make the document somewhat different from other information m= odels, but we believe that those who read the information model should un= derstand the purpose of each element and that the only way that they can = understand those purposes is to see why the elements are there. >=20 >> I would prefer MAY, MUST, or SHOULD be used consistently instead of OP= TIONAL >> and RECOMMENDED. Both are used here. >=20 > We have chosen terms based on how they best fit the structure of the su= rrounding grammar. If we need to choose one set of terminology, we can do= this, but it will require substantial rephrasing. BCP14 does not give gu= idance on using only one of (MAY,OPTIONAL) or (SHOULD,RECOMMENDED) consis= tently. Is there a reference that gives guidance on this topic? BCP14 is where I'd go so leave it. >> The draft is split into five lists, with 10 pages of Manifest Informat= ion >> Element descriptions presumably forming the basis of the draft, but fo= llowed >> by the bulk of the document as the Security Consideratios section. I = found >> the organization confusing, too abstract, and somewhat circular. In s= ummary: >> >> o manifest elements satisfy one or more requirements >> o threats are mitigated by one or more requirements >> o security requirements (REQ.SEC) mitigate one or more threats >> o user stories are satisfied by one or more usability requirements >> o usability requirements (REQ.USE) satisfy user stories >=20 > Would you find it less confusing to order it as follows? >=20 > o elements > o requirements > o threats/user stories Yes, I think that would really help. > The working group was quite clear that the list of information elements= should come first and be justified by subsequent sections. They belong up front, if you reorg it that'll probably go a long way. >> pp.7 "the DNS name space ID" >> >> This implies private DNS namespace may be a concern, and I'd like to >> understand why and how, because this is based on Trust Anchors as desc= ribed in >> RFC6024. What other DNS namespaces are under consideration? >=20 > This is an explicit references to RFC4122. The full sentence under disc= ussion reads: >> Recommended practice >> is to use [ >> RFC4122 >> ] version 5 UUIDs with the vendor's domain name and >> the DNS name space ID. >> >=20 > RFC4122 says (https://tools.ietf.org/html/rfc4122#section-4.3): >=20 >> Allocate a UUID to use as a "name space ID" for all UUIDs >> generated from names in that name space; see >> Appendix C >> for some >> pre-defined values >> >=20 > And (https://tools.ietf.org/html/rfc4122#appendix-C): >=20 >> /* Name string is a fully-qualified domain name */ >> uuid_t NameSpace_DNS =3D { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8= */ >> 0x6ba7b810, >> 0x9dad, >> 0x11d1, >> 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 >> }; >=20 > Therefore, when the suit-information-model references =E2=80=9Cthe DNS = name space ID=E2=80=9D it is referring to the UUID in RFC4122, Appendix-C= : >=20 >> 6ba7b810-9dad-11d1-80b4-00c04fd430c8 >=20 > Would it be clearer to rephrase the original text as follow > >> Recommended practice >> is to use [ >> RFC4122 >> ] version 5 UUIDs with the vendor's domain name and >> 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (the DNS name space ID). Yes, it would be. > As it happens, the SUIT working group has discussed the possibility of = using Private Enterprise Numbers in place of UUIDs for Vendor IDs as well= =2E This action is pending in the working group, as an update to the man= ifest specification. Okay. >> pp.17, "This model uses the S.T.R.I.D.E. approach" >> >> Microsoft's STRIDE Threat Model defines six types of threats: identity= >> spoofing, data tampering, repudiation, information disclosure, denial = of >> service, and elevation of privilege. Why call out this particular app= roach? >=20 > Some methodology must be used in order to perform a threat analysis. Th= is is the method we used and it defines the terminology used to classify = the various threats in the threat model. Is there a reason to remove this= reference given that it defines the terminology used in the threat model= ? It's the procedural point that you're pointing into Microsoft's=20 corporate web's description of the Microsoft Commerce Server 2002, which = may not be online forever. I guess you have to have a reference, hum. >> There may be traffic analysis and fingerprinting concerns if the manif= est is >> not encrypted, specifically if the vendor IDs are sent unencrypted. >=20 > I believe this is THREAT.MFST.EXPOSURE and/or THREAT.NET.ONPATH. The mi= tigation is: REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests, which is = implemented by: External Encryption Wrapper / Transport Security >=20 > See these sections for full details: > https://tools.ietf.org/html/draft-ietf-suit-information-model-08#sectio= n-4.2.7 > https://tools.ietf.org/html/draft-ietf-suit-information-model-08#sectio= n-4.2.14 > https://tools.ietf.org/html/draft-ietf-suit-information-model-08#sectio= n-4.3.14 That is the mitigation, and I even like it, so okay! >> pp.10, "...that version MUST be specified" >> >> It MUST be specified IF, but the element is OPTIONAL? >=20 > Correct. It MUST be supported by the serialization, but a given deploym= ent does not require it if, for example, it does not support differential= updates. So it is REQUIRED in the serialization, but OPTIONAL to impleme= nt in any given manifest or manifest processor. I thought so, so I'd just add that text explicitly to clarify. >> pp.10 Manifest Element: Expiration Time >> >> Time is mentioned but no time format is specified. Is synchronized ti= me a >> security requirement, and should specific time formats be specified? >=20 > In general, we try not to require a synchronised time source, since thi= s puts substantial requirements on a constrained device. You are correct = that, for an image to expire, some notion of time is necessary. This can = be complex or simple. We do not require millisecond accuracy; even displa= ying =E2=80=9CToday=E2=80=99s Date=E2=80=9D to a user would be =E2=80=9Cs= ecure enough=E2=80=9D for this use since, as noted in the draft: >=20 >> This element may also be displayed (e.g. via an app) >> for user confirmation since users typically have a reliable knowle= dge >> of the date. >> >=20 > Is there a reason to include specific time formats in the information m= odel, rather than a serialization thereof? No, serialization would canonicalize it coming out, and that was my conce= rn. Derrell --------------ms050003030705060505060508 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CqUwggUuMIIEFqADAgECAhBuYWaYcrycMAAAAABR05MeMA0GCSqGSIb3DQEBCwUAMIG+MQsw CQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5l bnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMDkgRW50cnVzdCwgSW5j LiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MTIwMAYDVQQDEylFbnRydXN0IFJvb3QgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjAeFw0xOTA0MTYxNTM1NTJaFw0zMDExMTYxNjA1 NTJaMIG3MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMf U2VlIHd3dy5lbnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50 cnVzdCwgSW5jLiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0 IENsYXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2DmtXj1lwZOXaWXvERtOSP7QMI+Ts82RQc2etqDeYwctILXqkwsQrZB6YjKa1BQn BmLHxn3cWxKJtqCT7ZP95YVxc0MXjP5ifP9xD/f59jlYd/7SPIxQUjX1+vsV6aY4tTzPiaOu 3VHVGbD70si3WdUvJh367CMOU2o0mXi9MwW1fBwMHK99NKgpwpr4QhyT2aZ+os/hGGQLUYms e5Dfshq79eelXyFC1FIrvM0AhAk+T3NKFPmckKwyk30jkFMElSneTR7ganOTMeT1OEqVomyJ sMzJugVaMzuSt4vhJFSt/XXRMPcPT9PEx39X78NNkWeTTkL1Ghq9O2WeAStQNwIDAQABo4IB KzCCAScwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUFBwIBFhpo dHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG F2h0dHA6Ly9vY3NwLmVudHJ1c3QubmV0MDAGA1UdHwQpMCcwJaAjoCGGH2h0dHA6Ly9jcmwu ZW50cnVzdC5uZXQvZzJjYS5jcmwwHQYDVR0OBBYEFOJJuewl3rcM3uVQGFtIzAyOFfKmMB8G A1UdIwQYMBaAFGpyJnrQHu995ztpUdRsjZ+QEmarMA0GCSqGSIb3DQEBCwUAA4IBAQBVuaCw N5r85cQphcyUe+RXqaYyUmVEqTWG/a98UJdX44vkCgzdD/+Cn4o6wbRun7Ak0kdCR3qfFA17 /5QOQ8DLOyR5X37Ytxby24lTLKKehNlc3japM8XQQFaJqLMq3MXXFYhWlFk4UHwXYLcDR7Xy A3hYuaL6HU92h+uGSDEcBeV+nXrk4FRgEfGvilHfd+8ozBjSVKOF6L1+fuJNkaFWYvJ4Qi64 nlmXDsk6K9f6P4FT8hXA2Cn6tQGAqCz8t6bn7ljtaxCMJ10LE+omiZDfWXv4PrkvgWnNqZEz Qw+E09HwEc7DjV9/fGqUhLR2AKkjYE/78rlymYPvOf7bmpSYMIIFbzCCBFegAwIBAgIRAI1S U9vc6Vc5AAAAAFVj5MUwDQYJKoZIhvcNAQELBQAwgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQK Ew1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRl cm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYw HhcNMjAwNjA1MTY1ODI5WhcNMjMwNjA1MTcyODI5WjCBnzEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQLEy5FbnRydXN0IENsYXNzIDEgSWRlbnRpdHkgQ2VydGlm aWNhdGlvbiBTZXJ2aWNlMR4wHAYDVQQDDBVkZHBAZWxlY3RyaWMtbG9mdC5vcmcxJDAiBgkq hkiG9w0BCQEWFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAM0lzjLFuD62oMZvzX4bx9JUT4wvdd/AbGIvYXvsY6VbsPF6HjtiLZlN2sZQ z973qCs3BXM0sMfCRbtNczoITG5KNkWoQNcCjIrtGDP1Op93HpAO7nIMXJQJ8qcKzZ1nO7Mv ciQ1GdHgvaZ2TyWUWSKCNhgbLT8gc4rB6XC5t6QHHKXKG9yc1huOq1TOVNvqCZJ7tx1ckumm Be7YU4NJTbu0XGSM0578jcuFbBzisj0gAt/Lj18Pi5Sqj3QqUT+xo9aofjydw+kKpinNyFQZ MqABXybuAO9/nzZ2cH0RE5MGx6pHb8GOhL6yvgqgUpu1QfovFrsTeBZbP24LViu7cisCAwEA AaOCAYowggGGMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwQgYDVR0gBDswOTA3BgtghkgBhvpsCgEEATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3 LmVudHJ1c3QubmV0L3JwYTAJBgNVHRMEAjAAMGkGCCsGAQUFBwEBBF0wWzAjBggrBgEFBQcw AYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwNAYIKwYBBQUHMAKGKGh0dHA6Ly9haWEuZW50 cnVzdC5uZXQvY2xhc3MxLXNoYTI1Ni5jZXIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2Ny bC5lbnRydXN0Lm5ldC9jbGFzczEtc2hhMjU2LmNybDAgBgNVHREEGTAXgRVkZHBAZWxlY3Ry aWMtbG9mdC5vcmcwHwYDVR0jBBgwFoAU4km57CXetwze5VAYW0jMDI4V8qYwHQYDVR0OBBYE FBldpeksJRT1eoN4ViLNnG4wgVdJMA0GCSqGSIb3DQEBCwUAA4IBAQBp4AZ3Z1ElfrhGuGjK BrtbVZBLQ122NbUZHF/msa83PGaqKYu+/NAARDM6oeGJg7K4J3qtM8UyGpuhvQI/GUMdiNiq x7Km0R0iqadG59smeNNvE+B4o7q95v8k3A0nd57DXmlNUYm+Xv/UIuNy18PAokYye0xiLOoV uHQPFpdN2TyLbHLbQmjwHa/FeHlQYw9xc4byRxDDg62g4bzcRgbuCEgzh4m3sMoIVgLeuiFT JWSpvnzBJSMWAMeBbs5LYN531kwFA/eSk/FQ4aiUl5cpkpUKjq3yPrUIvIIioYsQwQ11P13B Le+ll7ECwxX8egXWMAh/ca9dmElbgVUcqnjmMYIEmDCCBJQCAQEwgc0wgbcxCzAJBgNVBAYT AlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUgd3d3LmVudHJ1c3Qu bmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJbmMuIC0gZm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBDbGllbnQg Q0EgLSBTSEEyNTYCEQCNUlPb3OlXOQAAAABVY+TFMA0GCWCGSAFlAwQCAQUAoIICmzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMTkxOTU3MDNaMC8G CSqGSIb3DQEJBDEiBCBZuKR+bIPmnlp9nIGSt3pLEvZKR923AhZxbMDOXR5e2zBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHeBgkr BgEEAYI3EAQxgdAwgc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMu MSgwJgYDVQQLEx9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAo YykgMjAxNSBFbnRydXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNV BAMTIkVudHJ1c3QgQ2xhc3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYCEQCNUlPb3OlXOQAAAABV Y+TFMIHgBgsqhkiG9w0BCRACCzGB0KCBzTCBtzELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVu dHJ1c3QsIEluYy4xKDAmBgNVBAsTH1NlZSB3d3cuZW50cnVzdC5uZXQvbGVnYWwtdGVybXMx OTA3BgNVBAsTMChjKSAyMDE1IEVudHJ1c3QsIEluYy4gLSBmb3IgYXV0aG9yaXplZCB1c2Ug b25seTErMCkGA1UEAxMiRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQSAtIFNIQTI1NgIRAI1S U9vc6Vc5AAAAAFVj5MUwDQYJKoZIhvcNAQEBBQAEggEAiRp2CkNHLmHqRWxQYFzJ73TrQNee 4fr0uIjQIFbVWROvlrn//CyfbAOLKa8SNRW8Ok8dny4s8s+Udp4sfOMUfCLXJ5FHzUJtorpk wrakY93Zo9/BxAfPwOXtuxHhIYJ0Q5TL37f+ppoCmAew/mPnklX6duxQb3vgj2esaM1iFVLW lVAJsGsWFbL9DB4mqTSuUQGktvU9nymhm129eXCpOTZwu7Z/YH0g+sSNdpDErXyS6loMOkoH f0nT9lYJ/DIIxWUfwEAAjXnFYL6x2WBLY2Qwo6tj9FXIQdfnuuzgqlPXlAdFwHkhQ+LCXlUT Q5j7b/i9GDj+1KgheYWrpbeZHAAAAAAAAA== --------------ms050003030705060505060508-- From nobody Thu Nov 19 15:59:20 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E383A13C1; Thu, 19 Nov 2020 15:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYGVJUlSA8vP; Thu, 19 Nov 2020 15:59:17 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680138.outbound.protection.outlook.com [40.107.68.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8FF3A13C0; Thu, 19 Nov 2020 15:59:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nYfcttjI9cw0NfWr2flcF5bHwQ05NOKr7f2rHARPMNlHE+r7ce2xKP3iDx/W/t0/2fwzeFpmJ7tDQ6/xL9qAzKZ9nMRHBovDRQW9Lkij3/YvrOM41HRF1SMyZbq64QwjZeDwbk7ykml+r55UvsWbAY7BabNk3fMEg+8l3UCSo+s3FrKpYUSo6mp9GLXAQB+QKIcSpafk7R6ZB4ev+vGcvD7QxMAH1yvV9TppWVs/1SgH1DzOhUcksHevabMjlCk7VGClQqocVVQ2+3QCek6x8O9aks8jMjJqvoXRruEi07ypbaT/9uCY6LepL+bHNfbdWfSV+qAOrAeEdeaW3cqnAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xCNxtEqorFzRM9tRtyM1EVKsBufE8/tytHR+gypqmO4=; b=Jy97mnZVmDsuQyFuFpM9RjdTju1B2cTy9SPf3uH+xo4/0x6Txh8rN+YZnyqGi6zz7rOINNCAlMfwVyDB16Dh9aoptlw6q2OZMvOOgyy9+nz06TXcu8frT87QOsl8n/yAmPAh83yskYd/9BcKL7SCGEotuzVMFAF+E/SQGh8piTu4tpBsTTFBUCxa7DiEN/zsIOHHzdcQ7WXeQMUBf9WJ1Kn3i3NqCbGRsLQkH08FOATr/4gmrSN2a5640pHjt2+V7ORBK3JBK0ZxKC+Z24GEjEpa3hKV5ApFyv+I2hkYiW6UcPz1LWN+XEEk5EQlzfYmo3DYtcQUVqSJH153ysIilQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xCNxtEqorFzRM9tRtyM1EVKsBufE8/tytHR+gypqmO4=; b=b6lWzwEt1mT6FgBJYT0J7Nuh0lYeyXBE/UlQkG+DQlyO8Z3LfPrTz7D5WdazEHowxLFFjD48nIfBzgey0Vgl/8BAfbCzN2tgzybmsZlPy1YgJcLPJ+DzuhS382JL10Dvs3IRvhEb8uJJz7U+hIQA2AjXyYZ5q5yMhjStkvYGUZk= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by MN2PR21MB1488.namprd21.prod.outlook.com (2603:10b6:208:203::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.4; Thu, 19 Nov 2020 23:59:15 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::1cf:66d1:f9b0:bfec]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::1cf:66d1:f9b0:bfec%5]) with mapi id 15.20.3611.004; Thu, 19 Nov 2020 23:59:15 +0000 From: Dave Thaler To: suit CC: teep Thread-Topic: Uninstalling a SUIT manifest'ed component Thread-Index: Ada+zri55ao4P5mJTqGBS3/Aq5J8eQ== Date: Thu, 19 Nov 2020 23:59:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-11-19T23:59:13Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=43bd9036-02fc-4abc-9bf9-09f1ede378d3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:9780:8d0:edb3:1c76:a251:8439] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d4fdb9a2-a675-45f5-d71d-08d88ce71eb3 x-ms-traffictypediagnostic: MN2PR21MB1488: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yMDd/ykUuvwI/zwzyPuB3CVVYgsg7CU1rJXE4TncXlKsJj0lJuVSxli1jPwQ2iYYp27sNBqouPBY375+wcoopjJ6ZG3xZoHKkLGIb9Dx4/xNyDFzXwKTcFZwItSw+C/XRK61e1PxEx60iX+bl8xNTLOb6FPkWSSf4EeVo0tjMotPW0xudNpLY7p1t/hdQ7WTZ/lDhXgkR0Op+FYKOsSIQFwZt9VT7HGvfBir5nl9O4TRq7r+3X0ENmhb9JVYiPxRpEz2S+aPCVwRpRUhHmOBZiYDpdHShB9DxMnuDmfd15+lX/4MLTv7JLGocRFL0qJu x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(136003)(376002)(366004)(396003)(8676002)(83380400001)(478600001)(5660300002)(6506007)(52536014)(6916009)(8936002)(7696005)(66446008)(66946007)(66476007)(66556008)(64756008)(76116006)(86362001)(82950400001)(82960400001)(4326008)(450100002)(10290500003)(2906002)(8990500004)(55016002)(71200400001)(9686003)(186003)(316002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?aX8kIevhN70RXkS1rCR1tn/Lcj6FOd43DPX/P3/G0grox097icgWYadbUK7S?= =?us-ascii?Q?WNkp7+/hYBav6ZjdoN/NO5CkJxjB9xt0bdhxzw6t/hStMCo7LTo9rAbaUEPb?= =?us-ascii?Q?R1tb6eutoWA9fGDSzBpHMEfPbRVtZsObjI7bUFS6Frvuq09Fs7HeWaY6wTzM?= =?us-ascii?Q?4/iM5f6OjkC4zUhOpchkhvwGH5VBwKpcxBvvRrywR+u5nZzqk60wyQKUcv5g?= =?us-ascii?Q?QVg1ANliqTzZr86KSt8+RrSZnCs5pH6+/naqlvavflVqTAMb+vshLVHpbgZx?= =?us-ascii?Q?pSkZwjrLqhMtcA3QHmGbvMt7Tj/Llq7QUhAdjx+nj2lFOIxYlxkXqw7iZScs?= =?us-ascii?Q?OEBzs4syHatPIg1sKkG1sjhA3A5QBKxxO9iDqeSatYh8+WJ+9rKlVkaElWmw?= =?us-ascii?Q?RM1jVoUO9Bmmp6XOpnAkQZBIyc3G28Eo4iz8VqNGU7Q3Fx6327nCpwTmxvEK?= =?us-ascii?Q?Nb4afXbGM+QtnNpsc6dKYCGzID+afxdNED7dKttG11tMeW4BnjMJMLjRQJTl?= =?us-ascii?Q?dQj+ndfQrwDXWY3ow1+NSXrJopP/EJ8H8tXP/hmrsre/+uadc1kM6TqYGxir?= =?us-ascii?Q?yDKEQqHduEBVQD+xa9Si3mxH4RyxAaATOO9pRhZEqOvyN/5nMzSTek+Wx1Lu?= =?us-ascii?Q?08r1PohHVwLLyuLU00UQQof3s6UnRWeFHSQXbSDFQJQ6QwoWNTnn2Hgv/8SW?= =?us-ascii?Q?RimNmWDv0PpQxfcsnHx/6FERQTkgxImlOI1niMC+i5mNmA1UHVGcGN4Ue9Vx?= =?us-ascii?Q?2RX57V1+vfhQrCPm9D0EDLS0kbUc4QhIMY9CY2AxMIiVXNSQHp5855p4Wzij?= =?us-ascii?Q?IyOvmZt8ZS19O+cBvMWII+VoWaUWR2/82WH7ZdRC+/quxyP/c1J/co4qJ/Dy?= =?us-ascii?Q?i21WJsWh9OjGHDPUmcMkTvR+olg7xv7CtmUv/ZOxzVZe7QrCXQZ4TP4/f11F?= =?us-ascii?Q?omlnIxOvm051tNbpr6O831GRiDD8W0BRs36bmZFAQpGt2qxp2lA0I5fZGf+b?= =?us-ascii?Q?5lBegx0Y3TCRymMv3mhL1NeBxY24QgH2QkcpyY6fJ2PFSdA=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1027C5748111B35E58E9B369A3E00BL0PR2101MB1027_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR2101MB1027.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d4fdb9a2-a675-45f5-d71d-08d88ce71eb3 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 23:59:15.2812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FUCTJhVsBQqF4Ahj9sa2mP89GqaCd4Xpgv5pprQg+2fYoNsS4eg5d0f0LyiBffkUIR4hngWJ4CuReM4I7EPU/oWn/5UUgA1VIDSd1ACVAls= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR21MB1488 Archived-At: Subject: [Suit] Uninstalling a SUIT manifest'ed component X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 23:59:19 -0000 --_000_BL0PR2101MB1027C5748111B35E58E9B369A3E00BL0PR2101MB1027_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently the SUIT manifest spec talks about the "Update Procedure" for fetching dependencies and images, and installing them. The TEEP WG uses SUIT manifests for installing Trusted Apps, but also needs to be able to uninstall Trusted Apps on command. This begs the question of what is the correct "Uninstall" procedure for a c= omponent with a SUIT manifest. For example, is it a) Implied that one can simply delete all files referenced in the SUIT= manifest and the SUIT manifest? I suspect that might be insufficient in some cases. E.= g., if a SUIT manifest processor creates a Security Domain, is it always deleted i= f you delete the last component in it? Or should deletion be explicit? Controll= ing the answer to that question would require, I think, a SUIT manifest. b) Possible to create a SUIT manifest that when processed simply delete= s a component? E.g., bump the manifest version number, keep the component id= , and use empty payload and whatever commands are needed to clean up whatever state is needed? c) Something else? Currently the SUIT manifest draft doesn't say, and I think it should so we = can reference the answer from the TEEP protocol spec. If we have time, we might discuss = this in the SUIT meeting, but wanted to at least post the question to the list f= irst. Dave --_000_BL0PR2101MB1027C5748111B35E58E9B369A3E00BL0PR2101MB1027_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Currently the SUIT manifest spec talks about the = 220;Update Procedure” for

fetching dependencies and images, and installing the= m.  The TEEP WG uses

SUIT manifests for installing Trusted Apps, but also= needs to be able to

uninstall Trusted Apps on command.

 

This begs the question of what is the correct “= ;Uninstall” procedure for a component

with a SUIT manifest.   For example, is it=

a)      Implied that one can simply delete all files refere= nced in the SUIT manifest and

the SUIT manifest?  I suspect that might= be insufficient in some cases.  E.g., if

a SUIT manifest processor creates a Security = Domain, is it always deleted if you

delete the last component in it?  Or sho= uld deletion be explicit?  Controlling

the answer to that question would require, I = think, a SUIT manifest.

b)     Possible to create a SUIT manifest that when proces= sed simply deletes

a component?  E.g., bump the manifest ve= rsion number, keep the component id,

and use empty payload and whatever commands a= re needed to clean up

whatever state is needed?

c)      Something else?

 

Currently the SUIT manifest draft doesn’t say,= and I think it should so we can reference

the answer from the TEEP protocol spec.  If we = have time, we might discuss this

in the SUIT meeting, but wanted to at least post the= question to the list first.

 

Dave

--_000_BL0PR2101MB1027C5748111B35E58E9B369A3E00BL0PR2101MB1027_-- From nobody Thu Nov 19 20:34:43 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833A73A1834; Thu, 19 Nov 2020 20:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1qiYLY6NL-K; Thu, 19 Nov 2020 20:34:32 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7813A1833; Thu, 19 Nov 2020 20:34:28 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 04C2B548019; Fri, 20 Nov 2020 05:34:22 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id ED00E440059; Fri, 20 Nov 2020 05:34:21 +0100 (CET) Date: Fri, 20 Nov 2020 05:34:21 +0100 From: Toerless Eckert To: Benjamin Kaduk Cc: Brendan Moran , Russ Housley , "suit-chairs@ietf.org" , suit , The IESG , "draft-ietf-suit-architecture@ietf.org" Message-ID: <20201120043421.GT39343@faui48f.informatik.uni-erlangen.de> References: <160456913386.24093.10722400425795162498@ietfa.amsl.com> <20201119111024.GD39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201119111024.GD39170@kduck.mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:34:37 -0000 Benjamin, *: I do not think that the simple extension of the current text explanation to include "and the trend in quantum annealing capacity" would help: >From reading Brendans text below and doing a quick search through [quantum-factorization], it looks to me as if the conclusion currently written into the draft "... approximately 2030 ..." is an original research conclusion by Brendan et.al. and can not be directly found in [quantum-factorization]. The actual reference for the conclusion is the text below from Brendan, and if the 2030 prediction is to be kept in the text then readers should be made aware of this original research. I would obviously like to see the three paragraphs from Brendan put somewhere into the draft (appendix or the like), but if the authors worry about length, then they could simply put a reference to Brendans email into the draft (aka: see [https://mailarchive.ietf.org/arch/msg/suit/Ao2OlGo0yhjLncVftTLAJ2jjw2E/]) Cheers Toerless On Thu, Nov 19, 2020 at 03:10:24AM -0800, Benjamin Kaduk wrote: > Hi Brendan, > > Thanks for the extra reference and discussion about the timescale estimates > for quantum computers and integer factorization. (And for accepting most > of my other comments.) I see now how the factorization-by-annealing > reference was intended to be used, and had not been paying close enough > attention to know the 5640-qbit and doubling-every-two-years numbers for > D-Wave. > > If I was going to suggest a change to the text, it would be quite small, > perhaps something like "based on current research [quantum-factorization] > and the trend in quantum annealing capacity". > > Thanks again, > > Ben > > On Wed, Nov 18, 2020 at 10:05:44PM +0000, Brendan Moran wrote: > > We will take on board the majority of these comments. > > > > WRT the PQC time horizon, quantum annealing attacks on RSA are dependent commercial quantum annealers. > > > > The paper in nature shows the factorisation of 376,289 in 94 qubits. In fact, other researchers have factored 1,005,973 with only 89 qubits [1]. With this second algorithm, characterised as O(log^2(N)), RSA-768 would require 147,454 qubits. D-Wave has shipped quantum computers with 5640 qubits already. They have a historical average of doubling the number of qubits every two years. Based on this trajectory, they should be shipping a quantum computer that can break RSA-768 in approximately 2030 (log_2(147454/5640)) = 4.7 => 9.4 years. RSA-2048, then, would be broken between 2 and 4 years later, and RSA-4096 a mere 2 years after that. > > > > This is a naive analysis. However, it is intended to show that a scalable general purpose quantum computer is not the only threat to current cryptographic techniques, that the time horizon is not long, and that urgent action is required to ensure that devices with long lifetimes account for EITHER cryptographic agility or quantum safety, preferably the latter, since quantum safe algorithms require much more data than classical asymmetric crypto and, therefore, require extra considerations, particularly when used in constrained IoT. > > > > Obviously, the hole in this analysis is that RSA is not common in IoT. I have not yet found equivalent research that shows how a quantum annealer could attack ECDSA or EDDSA. I assume that there are research teams working on this. We should prepare ourselves for the potential of that particular revelation. > > > > We have not gone into this detail in the architecture because it seems both orthogonal to the general discussion in the architecture, extremely time-sensitive, and extremely algorithm-sensitive. It will be an irrelevant prediction and analysis within a handful of years. > > > > Best Regards, > > Brendan > > > > [1] https://link.springer.com/article/10.1007/s11433-018-9307-1 > > > > > > > On 5 Nov 2020, at 09:38, Benjamin Kaduk via Datatracker wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-suit-architecture-14: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Does the XIP case mean that repeated firmware updates would have > > > potential to cause undue wear on the fixed flash cells that hold the > > > firmware image? If so, this might be noted in the security > > > considerations. > > > > > > I am not sure that I have fully digested Bob Briscoe's detailed review > > > comments, but it seems like we may want to continue to reflect on which > > > portions of the architecture will be optional to implement, and how we > > > might indicate that in the document. > > > > > > I also made a pull request for some editorial nits at > > > https://github.com/suit-wg/architecture/pull/15 . > > > > > > Section 1 > > > > > > otherwise difficult. Firmware updates > > > for IoT devices are expected to work automatically, i.e. without user > > > involvement. Conversely, IoT devices are expected to account for > > > user preferences and consent when scheduling updates. Automatic > > > > > > I can't quite tell if the "Conversely" case is intending to refer to IoT > > > or non-IoT devices. > > > > > > The firmware update process has to ensure that > > > > > > - The firmware image is authenticated and integrity protected. > > > [...] > > > > > > - The firmware image can be confidentiality protected so that > > > attempts by an adversary to recover the plaintext binary can be > > > [...] > > > > > > Perhaps it's just because Bob Briscoe's comments are fresh in my mind, > > > but there seems to be something of a mismatch across these texts -- we > > > "have to ensure" that the firmware *is* authenticated and integrity > > > protected, but only that the image *can be* confidentiality protected. > > > Is it really the case that we can ensure that an update process *can be* > > > confidentiality protected, or is the confidentiality requirement more of > > > a requirement on the architecture than on actual deployment? > > > > > > While the IETF standardization work has been focused on the manifest > > > format, a fully interoperable solution needs more than a standardized > > > manifest. For example, protocols for transferring firmware images > > > and manifests to the device need to be available as well as the > > > status tracker functionality. Devices also require a mechanism to > > > discover the status tracker(s) and/or firmware servers, for example > > > using pre-configured hostnames or [RFC6763] DNS-SD. These building > > > blocks have been developed by various organizations under the > > > umbrella of an IoT device management solution. The LwM2M protocol is > > > one IoT device management protocol. > > > > > > We might put some forward references to things we do cover (like status > > > tracker(s)), and a reference for LwM2M as well. > > > > > > Section 3 > > > > > > Hence, the following components are necessary on a device for a > > > firmware update solution: > > > [...] > > > - a status tracker. > > > > > > Earlier we said that having the status tracker on the device was fairly > > > uncommon. > > > > > > Section 7 > > > > > > time horizon for quantum-accelerated key extraction. The worst-case > > > estimate, at time of writing, for the time horizon to key extraction > > > with quantum acceleration is approximately 2030, based on current > > > research [quantum-factorization]. > > > > > > I'm not sure that I see how the reference suports the "approximately > > > 2030" statement. > > > > > > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit -- --- tte@cs.fau.de From nobody Thu Nov 19 22:12:41 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F913A1908; Thu, 19 Nov 2020 22:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=b0hVgRdq; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=b0hVgRdq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTa1B3_xu9f4; Thu, 19 Nov 2020 22:12:36 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80088.outbound.protection.outlook.com [40.107.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C942B3A1905; Thu, 19 Nov 2020 22:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XFLFWzkbVfAYO73a+eS7l3D25rOH4uBaUE2aY6IUUBo=; b=b0hVgRdqVD8g59oXRa1bEtCLrlvpB7JEe5zMBvVVg3V3+Fbxj3ISDXrTu2jryclI6vIJM7dze8wPalmtUYTHlYt44BZi9aivRYmWE0REClsks1GUUFeII7Jp6QFq+wOxZu/Y2f+wkcOVv8d6wBwLdM2u6RRsn6Anq4zzKRIj6sM= Received: from AM6P195CA0058.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::35) by HE1PR0801MB1994.eurprd08.prod.outlook.com (2603:10a6:3:50::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Fri, 20 Nov 2020 06:12:32 +0000 Received: from VE1EUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::6c) by AM6P195CA0058.outlook.office365.com (2603:10a6:209:87::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 06:12:32 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT005.mail.protection.outlook.com (10.152.18.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 06:12:31 +0000 Received: ("Tessian outbound d6c201accd3c:v71"); Fri, 20 Nov 2020 06:12:31 +0000 X-CR-MTA-TID: 64aa7808 Received: from f35e2dc987a5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A2D4D8C9-7A13-4A25-A927-A288D5C382B9.1; Fri, 20 Nov 2020 06:12:26 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f35e2dc987a5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 20 Nov 2020 06:12:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Noz/y51CYV1nk4zrXxrQfnMrKHrzlQC92z25Rogwn1Kf8Fcn3dvzIPnsVImWPB/0MEIYSyjvKntVpqxAjtB5WpgphEYNLDMIm1A/sAA/lC8zpgGsWcuOQ2o6GYSjAblfxlWl1zDvbJ5huTE0okWvK21xlhVM9q/9JO3HX4z20R3/Ji4fU8zs2WVdytqSkNp/+M7elZozUhn9PHhvz1HOVTHCk8EvzEmuiOXhd/p134B5jogA07MS4ZkHtfve657CRc2Y0uEaLo3SEsqZTr0RpU1bQfNL6/wzlFzMTYCJST0H89KHvGxk0agpcNr5f1v67WxzaIFNWOVrfTQ4Ra728g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XFLFWzkbVfAYO73a+eS7l3D25rOH4uBaUE2aY6IUUBo=; b=et3y+wMjZ4Tf3CFqQSsGHdWuwkJ6dqJtYmjAlbJvREBG1VWuprs+/YNqKHUvWSBzVUZ0t+BnBrQSgLgvPUs6hw/8HXbPaCb1gbunY4UvjMJO0kGBiQrXOxOsaj1r1SWqiJ8Uz/KEb4HgWQkrLlL7fQoBPCFS8o0MA8CT1ELaMwt7vn659gv/Iz2EhHYo1f36oPXjKPBHMaT50nusmViL0F0z2ccRLqfsskqLIjHQa0HA2S5sYj4ucNd24OdRfyJPeke2VodKN2fdOmpl+NgFX4f/tZWJbj9CWAhshbwZC2kXILufYV3Xfp3xpce9RuznTLC589+6SNLIZAYpN1cEcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XFLFWzkbVfAYO73a+eS7l3D25rOH4uBaUE2aY6IUUBo=; b=b0hVgRdqVD8g59oXRa1bEtCLrlvpB7JEe5zMBvVVg3V3+Fbxj3ISDXrTu2jryclI6vIJM7dze8wPalmtUYTHlYt44BZi9aivRYmWE0REClsks1GUUFeII7Jp6QFq+wOxZu/Y2f+wkcOVv8d6wBwLdM2u6RRsn6Anq4zzKRIj6sM= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM8PR08MB5810.eurprd08.prod.outlook.com (2603:10a6:20b:1d2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Fri, 20 Nov 2020 06:12:24 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48%7]) with mapi id 15.20.3564.028; Fri, 20 Nov 2020 06:12:23 +0000 From: Hannes Tschofenig To: Robert Wilton , The IESG CC: "housley@vigilsec.com" , "suit-chairs@ietf.org" , "suit@ietf.org" , "draft-ietf-suit-architecture@ietf.org" Thread-Topic: [Suit] Robert Wilton's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) Thread-Index: AQHWs2wTeQT1S56uYUeOGQwG4yU306nQoMQQ Date: Fri, 20 Nov 2020 06:12:23 +0000 Message-ID: References: <160457792503.2410.4847314047672327887@ietfa.amsl.com> In-Reply-To: <160457792503.2410.4847314047672327887@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 822A926EB783A945B80264E519A1F4E2.0 x-checkrecipientchecked: true Authentication-Results-Original: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.118.246] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1749749b-ac57-45c1-e32d-08d88d1b441f x-ms-traffictypediagnostic: AM8PR08MB5810:|HE1PR0801MB1994: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: WVr4z4t4q5u3okRuMckFyUf3cfBtXkjJNVRP3EkRvYQANcxX4BFsxqk5hyIWrZfgjXraPSNrkDdAsOLALBhM5MAK+I1o1ZhRhEsu7JJwY8hL8TAuT1cyqYvMQurgN18UNKGFq+ecIIUAq4qKArk9aCy+IMEh6H5Qe4MmVkVr0hQJXussT2dHdsEgQtIEgsH0LYnnr+R7NuN8diPfmQL9Yf5FHYnXus52JKW0rDHcXqWaBeTtckj+K5131MSUKIqcr55i5E6yIrn3TyxpdWoPgqFZpa46fAnqr1Mk5MmJkpSNnoYBygtb4IOEQgy6nZdvCRmvZNksbICSS0+OT6TTtruI0FB/lFyquVxXmjsByuxT9FW8TWz81MQhu+QgGa7/4iYf/x7lCPy68k4CHsMiGg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(39830400003)(136003)(396003)(76116006)(186003)(5660300002)(66476007)(110136005)(26005)(9686003)(55016002)(52536014)(86362001)(66946007)(4326008)(316002)(2906002)(966005)(33656002)(66446008)(8676002)(478600001)(66556008)(54906003)(7696005)(8936002)(6506007)(64756008)(71200400001)(53546011)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yuuynUUiWWvG3MgcrbArtx/5FNqAYfAD9Vgf72a53sP3BPKY4cH/dX0qkKM1+Yns2e1JRrTBOk/bx48ThEWQBm2t1n7PmX+XlMw9dy+U1TiUVC5eHWstVyfuyxHJ+OwKx8HC0rvx5IPRFP4JFhypTWlEE1wDBS2AvWrkG9bWv+4IxZbWrN8l4pfDo0udsGiEH/TW+z2t05Cg7Mokur4BccPrGpOzdNCPtMpSguEz2bdCIQcDb9tGpUnC8GCmF4yG3eu34YwFjCDVQr1ncrVkjBlt//XOrdrfaYBLvRfWv0lFJ/j1AaNRmp4JvmT08yq1dRTknI8CBzInupBBBAtmpzweRYH34Ai9Lyq0Dol81nPd63rLZBek+emN39AgAdeZtE9uSQkThRmfkyDSVxOdRORtpYi5LecDc+t74pK5MU95SGA33rNkiYGNQuhSjLstx1ettrpsMgjBzr+NwStlNgSgCRtMfekk05Yb5rQYuRlR4zQEe60jUcYF71lXSBhvLRWyatz5L25QtSOuZ375qUL86SMdYqeNv+2c84cTsk9C8rHdVDc4lcSYQOSvdcXgTOZnMColTIByOU7TyEwczGR0hM6jswW9+DEEaGRfFqEw+8UQ64skW5pIZqldH+k6WftPrNX6DWebXwSzLT6U1g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5810 Original-Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT005.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: c77ab1f8-7cfe-48b8-5250-08d88d1b3f54 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MmBAMxyhS0I29C12YmKpRqdiANg3ix8d2aMYEKRWGZdYmeYhG2n+Mx9vJhobXo3N7sw1otd9u9PdaHpSlFOD4sJBRo5XZeug5VJofd9VbR/gpHcZYelU7zkU+RvWZ/o8bDe9LcuDHzn9XOVfdXkJ5+sHtZ4bDIpyfJacuchveEWLfPyyx+VhITGFH/4/cLW+7pWO0Esmn4vbRMLKF23ka9ly7+p7/PpwjHRRLLwWZzPou+PjJxSXlPzj4JONelu7IknZ0WUeQ3aBRozU9BD5CpB2jRZIngrGH1yGZHatllx+kS63iMexpYEwJUsArtpl5Lrvl6vjnWj121UfcrKyHod/0+9mNvt0FCe0LTXgJFU+R0vgxCXUKgZv3IPH7IR97Yj+TqQ1V87z+Y6fHEfFNzJgYSQ2WjGtvmdJkZda+HZI4NfedFF7toSMrO8I84TICp7BP6Mt3SqhqTVd1CiPBLrurYXzoJYoavcNUMfbV18= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(396003)(39850400004)(46966005)(316002)(110136005)(26005)(52536014)(478600001)(8936002)(8676002)(33656002)(86362001)(186003)(450100002)(336012)(82310400003)(5660300002)(54906003)(9686003)(55016002)(7696005)(6506007)(70586007)(53546011)(70206006)(2906002)(83380400001)(356005)(81166007)(82740400003)(966005)(4326008)(47076004); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2020 06:12:31.6950 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1749749b-ac57-45c1-e32d-08d88d1b441f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT005.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1994 Archived-At: Subject: Re: [Suit] Robert Wilton's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 06:12:40 -0000 Hi Rob, Thanks for the review. I have created a PR with the changes. You can find t= he PR here: https://github.com/suit-wg/architecture/pull/19 Ciao Hannes -----Original Message----- From: Suit On Behalf Of Robert Wilton via Datatrack= er Sent: Thursday, November 5, 2020 1:05 PM To: The IESG Cc: housley@vigilsec.com; suit-chairs@ietf.org; suit@ietf.org; draft-ietf-s= uit-architecture@ietf.org Subject: [Suit] Robert Wilton's No Objection on draft-ietf-suit-architectur= e-14: (with COMMENT) Robert Wilton has entered the following ballot position for draft-ietf-suit-architecture-14: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document. I found it informative and interesting. One minor comment: 7. Securing Firmware Updates The information that is encrypted individually for each device/ recipient must maintain friendliness to Content Distribution Networks, bulk storage, and broadcast protocols. Although I think that I understand the intent here, I'm not sure whether fr= iendliness is the best choice of term here. I presume that it means "must = be done in a way that is usable with". Regards, Rob _______________________________________________ Suit mailing list Suit@ietf.org https://www.ietf.org/mailman/listinfo/suit IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Thu Nov 19 22:13:34 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AD13A190E; Thu, 19 Nov 2020 22:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=mfg1UsBg; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=mfg1UsBg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPNHMy0b-6hg; Thu, 19 Nov 2020 22:13:25 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140080.outbound.protection.outlook.com [40.107.14.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC87F3A1909; Thu, 19 Nov 2020 22:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CIXFgLC4waWNlHGgHKbUFLG3CdGXJVl7UuZEuOFHvus=; b=mfg1UsBg1Qlez0EXFamZ0mOuhx0pZAmlNJ31iiBrINMNRcLBEbJ5MpRZj/Rf+yKhECVtu+b+cWbrVa8l84QI0912wrepTWbjwhyRYpiGNKTHmJtEsyoRYl3gopNAswT1jAJ4MOY3eonvo6fla109FBH1Gt8hULn8lgyQhfA1yQE= Received: from DB7PR02CA0013.eurprd02.prod.outlook.com (2603:10a6:10:52::26) by PA4PR08MB6126.eurprd08.prod.outlook.com (2603:10a6:102:ea::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Fri, 20 Nov 2020 06:13:21 +0000 Received: from DB5EUR03FT009.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:52:cafe::2c) by DB7PR02CA0013.outlook.office365.com (2603:10a6:10:52::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 06:13:21 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT009.mail.protection.outlook.com (10.152.20.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 06:13:21 +0000 Received: ("Tessian outbound 13ed5f5344c0:v71"); Fri, 20 Nov 2020 06:13:21 +0000 X-CR-MTA-TID: 64aa7808 Received: from 4e2a89c87dd7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9D6BC86E-DDE7-44A2-86B6-1EA44854ACCB.1; Fri, 20 Nov 2020 06:13:16 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4e2a89c87dd7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 20 Nov 2020 06:13:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aohWG9HcdRju/VXYH2okLKEAT/Iwqdds2NkEKaXGU0fsaU8NV07MDI2ohscXTYsbO44sE/k3Zm+Ci7gLnBb6a5r/1sNGNd0vy7CdXP3gv2Etj/z1ZW77P0IPUeIoclp6JKq0vI55s9eSInNgkgKxmr5DNHssWxYwRzpHDEoX0q4l7SCLHRDguPzpnwhiesq/8wGISP6wSyP+wlNfpHvF7FG0iVCHl40hedkwJGjcZDWNttVZU5mUozFIao6EGGkwqKpe7tJraxOcor9e9oHQGbb7V6yDFQA6zVtl2hfaCj6K4uChfPnEiQmQKeTyUeF17DP249VOd3VvYF0wZrJ+QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CIXFgLC4waWNlHGgHKbUFLG3CdGXJVl7UuZEuOFHvus=; b=jZvfR61wtNJ8bAn744iEQL5vkvA2Jml931xjesP3lVTY2fqydr9dY17+ZyDDSXwdVBeU4mvU06y0vZJICz3kITfWNLPXWNqLMcPn+2zC5fOz8kz/H+AIROnqqJvTTYI/rtjyBPP6heXzBztjrunIwn+uvR+Wqr2flapjAkWlveCImfJ7iG1Q0qSclHmNxlP+V2h6KjMrBsq3Eenuyn3SBSzRb6hoEbiTMlHTdbU9nu76jsp/jjABz7WA0w2on0tTHaKmciPan+ktrx7T0/33eiM2VAqNA4NN5rQMWzwlWpW71gjTrvMgx5tYVSyK4kgPtUxCuDWLEE3ahjGir3+/dQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CIXFgLC4waWNlHGgHKbUFLG3CdGXJVl7UuZEuOFHvus=; b=mfg1UsBg1Qlez0EXFamZ0mOuhx0pZAmlNJ31iiBrINMNRcLBEbJ5MpRZj/Rf+yKhECVtu+b+cWbrVa8l84QI0912wrepTWbjwhyRYpiGNKTHmJtEsyoRYl3gopNAswT1jAJ4MOY3eonvo6fla109FBH1Gt8hULn8lgyQhfA1yQE= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM8PR08MB5810.eurprd08.prod.outlook.com (2603:10a6:20b:1d2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Fri, 20 Nov 2020 06:13:14 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48%7]) with mapi id 15.20.3564.028; Fri, 20 Nov 2020 06:13:14 +0000 From: Hannes Tschofenig To: Barry Leiba , The IESG CC: "draft-ietf-suit-architecture@ietf.org" , "suit-chairs@ietf.org" , "suit@ietf.org" , Russ Housley Thread-Topic: Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) Thread-Index: AQHWsHWdvpwATGgBck64F+2gkMub96nQp1UA Date: Fri, 20 Nov 2020 06:13:14 +0000 Message-ID: References: <160425219933.2164.12165140117377106860@ietfa.amsl.com> In-Reply-To: <160425219933.2164.12165140117377106860@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 616B5C18BC7C414086C9D58E541378F9.0 x-checkrecipientchecked: true Authentication-Results-Original: computer.org; dkim=none (message not signed) header.d=none; computer.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.118.246] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: ea838fb2-e240-45df-aea8-08d88d1b616f x-ms-traffictypediagnostic: AM8PR08MB5810:|PA4PR08MB6126: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: wV2ZeO8s8N0TAOgs9l7NL9n5dSu5gSQkB051IeaOh0Ag6Qv9ffmvGo0egLdnjqS1Qwaw/q2hHhBpWThJZYYy1+iv2e82B24axitC7dKr0gGFn+rE7GRWhjGig3958Bpbag4QfoJSWLyz7iPqrQ1Sw+qU+9TEZ/pz2XBfPptlcSehVLhtCFjhX2JMn8Crzvl+rQschpwNBbfBaaOQVaE7l+IuBF3B3dH7OZPlAQKlPf+LlTAVvB8Vlh/KAOW7sCFTjK9i4dVpFmT3dYuZoq5VWXQf9MSJQNMMFphu/zltHEQhYOd4ZxBeWcPk0p+S7O3LVEBoQbn4LCp83x5RznVgKVVzOalp7zr4qzTx6cGtzjr31keqLjaDOnMczWGKeHuXcJz9lYQWdhagcpFrL6Il6Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(39830400003)(136003)(396003)(76116006)(186003)(5660300002)(66476007)(110136005)(26005)(9686003)(55016002)(52536014)(86362001)(66946007)(4326008)(316002)(66574015)(2906002)(966005)(33656002)(66446008)(8676002)(478600001)(66556008)(54906003)(7696005)(8936002)(6506007)(64756008)(71200400001)(53546011)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: s8WT3L7QNzu//9wGFsWoOanktAhF4MuhsXat5LFuaKN7d/jkuvtV74lSnK5XyVUyLJHanc5+aCVdpT29kQFDq6hvD/n74k06rkYTbllhEMGMaLu6EgTEDHDxayBLPQtJ6HrzwngMSRgcltm8TTPjmqTkVvfDk/QgAE9m3DCiTu5BlgahFJy7kT0oaLb7Zw+qEe7QnWvVVdC4U/Gj2TYHojTeucJIlIuh4BcY7qlUpjN/Y2q9dKOog1epTRZ4y3j6RJciP4G9W8OP0kPKlWg0mG6KDkd7jbRNwSm1cUh3WF37vfcpYsdD8zfJsEYOxjJLUQ5iaT9NEsg5Tj4w1vvyYOSdNojhGV0h+YHE70WARNJEgIVKgMKaFqa4MVcSxOJKxcBNzjgqYbXfXZtjH+q6hok2PMqyWA+s3BKjBuLQ0+T8cTfKCQZgpJS43SpmbCAfLZ9hsChlZv0G+bthLBfjh9jKnIvYEg1HjqrlryQM/kSnW+d16YK+8NyMS1N5MT4Sv8McTHj6nakAhPKmPnGjWaV/o2gwJQ0LYeWabfarsdvKBsrQ7Ns03NYgyCe0wJi4osajktLDiTSANijUpN7NetkDje+ZhbRz0GTrGfPPv5D6khid7LV0XOa1LvAFm0E5RsBpYxFePqDFzzOYkyvXtQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5810 Original-Authentication-Results: computer.org; dkim=none (message not signed) header.d=none; computer.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT009.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 146f192c-95e1-4151-5b6e-08d88d1b5d6d X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pR3q+53aB31fNjLYbPy0B07t1fq277h1AVMxQCdJBkD3R5NWiFMuU6DlQ/w0+qqjbdkxo61zjOnto/dfU9LeDANp3QwSQhX2f6wHyzFuGapaN5O/4ZLLf+S6KeUcBo/3p36oSfypi+N4oYGT7v91eRvnUskO1m2TSoTujT20m33I3iaTxclyA49xwG6IjwCN1a4nIss14n96R1nn4uTIt/dXpXVJu29+sBa9jWDdJYSsQ/eTP8uvW+lxnaUDcURVyX1enWRGnO/s2DJhvr3MBVQu37rAm+g3KL1rmHYXan+DVVKZmjWTm1WG7WI82HJFMxeYwHHbp72zXn+JHuYkrFF8e5b4lZe5BceXdt3Q/vJK/wye/FHe/2kFry/PXxHhRMJSu5NQGftS/xPyp8wdrC0Lo622Ak9PyhMDTglqvWjTngoAnMTCUsy23YIdRvxa2wAN3q7tT8RU+WfkKl7sITq6lDHXOK9L0CyBgAH5eAg= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(376002)(39850400004)(136003)(396003)(46966005)(8676002)(82310400003)(450100002)(9686003)(55016002)(336012)(107886003)(66574015)(33656002)(2906002)(186003)(478600001)(47076004)(316002)(54906003)(7696005)(81166007)(5660300002)(8936002)(6506007)(53546011)(82740400003)(4326008)(356005)(70206006)(70586007)(52536014)(26005)(83380400001)(86362001)(966005)(110136005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2020 06:13:21.1117 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea838fb2-e240-45df-aea8-08d88d1b616f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT009.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6126 Archived-At: Subject: Re: [Suit] Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 06:13:28 -0000 SGkgQmFycnksDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIEkgaGF2ZSBpbmNvcnBvcmF0ZWQg dGhlIHN1Z2dlc3RlZCBjaGFuZ2VzIGluIHRoaXMgUFI6IGh0dHBzOi8vZ2l0aHViLmNvbS9zdWl0 LXdnL2FyY2hpdGVjdHVyZS9wdWxsLzE4DQoNCkNpYW8NCkhhbm5lcw0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCYXJyeSBMZWliYSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVw bHlAaWV0Zi5vcmc+DQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDEsIDIwMjAgNjozNyBQTQ0KVG86 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtc3VpdC1hcmNoaXRlY3R1 cmVAaWV0Zi5vcmc7IHN1aXQtY2hhaXJzQGlldGYub3JnOyBzdWl0QGlldGYub3JnOyBSdXNzIEhv dXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPjsgaG91c2xleUB2aWdpbHNlYy5jb20NClN1Ympl Y3Q6IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc3VpdC1hcmNoaXRl Y3R1cmUtMTQ6ICh3aXRoIENPTU1FTlQpDQoNCkJhcnJ5IExlaWJhIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1zdWl0LWFyY2hpdGVjdHVy ZS0xNDogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1 Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K DQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtc3VpdC1hcmNoaXRlY3R1cmUvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQpOaWNlIHdvcmsgb24gdGhpczsgdGhhbmtzLiAgSSBoYXZlIGEgYnVuY2gg b2YgY29tbWVudHMsIGJ1dCBhbGwgbWlub3IuDQoNCuKAlCBTZWN0aW9uIDEg4oCUDQoNCiAgIEZp cm13YXJlIHVwZGF0ZXMgY2FuIGhlbHAgdG8gZml4IHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcyBh bmQgYXJlDQogICBjb25zaWRlcmVkIHRvIGJlIGFuIGltcG9ydGFudCBidWlsZGluZyBibG9jayBp biBzZWN1cmluZyBJb1QgZGV2aWNlcy4NCg0KTml0OiDigJxmaXJtd2FyZSB1cGRhdGVz4oCdIGlz IHBsdXJhbCwgYW5kIOKAnGJ1aWxkaW5nIGJsb2Nr4oCdIGlzIHNpbmd1bGFyLiAgSSB0aGluayBp dOKAmXMgYWN0dWFsbHkgKmRvaW5nKiB0aGUgdXBkYXRlcyB0aGF04oCZcyB0aGUgYnVpbGRpbmcg YmxvY2ssIG5vdCBoZSB1cGRhdGVzIHRoZW1zZWx2ZXMuICBBbmQgeW91IGNhbiBqdXN0IG1ha2Ug dGhlIHN0YXRlbWVudCwgd2l0aG91dCDigJxhcmUgY29uc2lkZXJlZOKAnS4NCkhvdyBkbyB5b3Ug bGlrZSB0aGlzIHZlcnNpb24/Og0KDQpORVcNCiAgIEZpcm13YXJlIHVwZGF0ZXMgY2FuIGhlbHAg dG8gZml4IHNlY3VyaXR5IHZ1bG5lcmFiaWxpdGllcywgYW5kDQogICBwZXJmb3JtaW5nIHVwZGF0 ZXMgaXMgYW4gaW1wb3J0YW50IGJ1aWxkaW5nIGJsb2NrIGluIHNlY3VyaW5nDQogICBJb1QgZGV2 aWNlcy4NCkVORA0KDQogICBEdWUgdG8gcmlzaW5nIGNvbmNlcm5zIGFib3V0IGluc2VjdXJlIElv VCBkZXZpY2VzIHRoZSBJbnRlcm5ldA0KICAgQXJjaGl0ZWN0dXJlIEJvYXJkIChJQUIpIG9yZ2Fu aXplZCBhICdXb3Jrc2hvcCBvbiBJbnRlcm5ldCBvZiBUaGluZ3MNCiAgIChJb1QpIFNvZnR3YXJl IFVwZGF0ZSAoSU9UU1UpJywgd2hpY2ggdG9vayBwbGFjZSBhdCBUcmluaXR5IENvbGxlZ2UNCiAg IER1YmxpbiwgSXJlbGFuZCBvbiB0aGUgMTN0aCBhbmQgMTR0aCBvZiBKdW5lLCAyMDE2IHRvIHRh a2UgYSBsb29rIGF0DQogICB0aGUgYmlnZ2VyIHBpY3R1cmUuICBBIHJlcG9ydCBhYm91dCB0aGlz IHdvcmtzaG9wIGNhbiBiZSBmb3VuZCBhdA0KICAgW1JGQzgyNDBdLiAgVGhlIHdvcmtzaG9wIHJl dmVhbGVkIGEgbnVtYmVyIG9mIGNoYWxsZW5nZXMgZm9yDQogICBkZXZlbG9wZXJzIGFuZCBsZWQg dG8gdGhlIGZvcm1hdGlvbiBvZiB0aGUgSUVURiBTb2Z0d2FyZSBVcGRhdGVzIGZvcg0KICAgSW50 ZXJuZXQgb2YgVGhpbmdzIChTVUlUKSB3b3JraW5nIGdyb3VwLg0KDQpUaGUgZGV0YWlscyBvZiB3 aGVuIGFuZCB3aGVyZSB0aGUgd29ya3Nob3AgaGFwcGVuZWQgaXNu4oCZdCBpbXBvcnRhbnQgaGVy ZSwgYW5kIGl04oCZcyByaWd0IHVwIGZyb250IGluIDgyNDAgYW55d2F5LiAgSSBzdWdnZXN0IHRy aW1taW5nIHRoYXQsIGJlY2F1c2UgdGhlIGltcG9ydGFudCBwYXJ0IGlzIHBvaW50aW5nIHBlb3Bs ZSB0byB0aGUgd29yc2hvcCByZXBvcnQgYW5kIHNheWluZyB3aGF04oCZcyBpbiB0aGUgbmV4dCBz ZW50ZW5jZSBhYm91dCB0aGUgZm9ybWF0aW9uIG9mIHRoZSBTVUlUIFdHLg0KDQpORVcNCiAgIER1 ZSB0byByaXNpbmcgY29uY2VybnMgYWJvdXQgaW5zZWN1cmUgSW9UIGRldmljZXMgdGhlIEludGVy bmV0DQogICBBcmNoaXRlY3R1cmUgQm9hcmQgKElBQikgb3JnYW5pemVkIGEgJ1dvcmtzaG9wIG9u IEludGVybmV0IG9mIFRoaW5ncw0KICAgKElvVCkgU29mdHdhcmUgVXBkYXRlIChJT1RTVSknIFtS RkM4MjQwXSB0byB0YWtlIGEgbG9vayBhdA0KICAgdGhlIGJpZ2dlciBwaWN0dXJlLiAgVGhlIHdv cmtzaG9wIHJldmVhbGVkIGEgbnVtYmVyIG9mIGNoYWxsZW5nZXMgZm9yDQogICBkZXZlbG9wZXJz IGFuZCBsZWQgdG8gdGhlIGZvcm1hdGlvbiBvZiB0aGUgSUVURiBTb2Z0d2FyZSBVcGRhdGVzIGZv cg0KICAgSW50ZXJuZXQgb2YgVGhpbmdzIChTVUlUKSB3b3JraW5nIGdyb3VwLg0KRU5EDQoNCiAg IEZpcm13YXJlIHVwZGF0ZXMgYXJlIG5vdCBvbmx5IGRvbmUgdG8gZml4IGJ1Z3MsIGJ1dCB0aGV5 IGNhbiBhbHNvIGFkZA0KICAgbmV3IGZ1bmN0aW9uYWxpdHksIGFuZCByZS1jb25maWd1cmUNCg0K R3JhbW1hciBuaXQ6IOKAnEZpcm13YXJlIHVwZGF0ZXMgYXJlIGRvbmUgbm90IG9ubHkgdG8gZml4 IGJ1Z3MsIGJ1dCBhbHNvIHRvIGFkZCBuZXcgZnVuY3Rpb25hbGl0eSBhbmQgdG8gcmVjb25maWd1 cmXigJ0NCg0KICAgVW5saWtlIGhpZ2hlciBlbmQgZGV2aWNlcywgbGlrZSBsYXB0b3BzIGFuZCBk ZXNrdG9wIFBDcywgbWFueQ0KICAgSW9UIGRldmljZXMgZG8gbm90IGhhdmUgdXNlciBpbnRlcmZh Y2VzIGFuZCBzdXBwb3J0IGZvciB1bmF0dGVuZGVkDQogICB1cGRhdGVzIGlzLCB0aGVyZWZvcmUs IGVzc2VudGlhbCBmb3IgdGhlIGRlc2lnbiBvZiBhIHByYWN0aWNhbA0KDQpNeSBmaXJzdCByZWFk aW5nIG9mIHRoaXMgd2FzIHRoYXQg4oCcbWFueSBJb1QgZGV2aWNlcyBkbyBub3QgaGF2ZSB1c2Vy IGludGVyZmFjZXMgYW5kIHN1cHBvcnQgZm9yIHVuYXR0ZW5kZWQgdXBkYXRlcy7igJ0gIEkgaGFk IHRvIHJlYWQgaXQgYWdhaW4gdG8gY29ycmVjdGx5IGludGVycHJldCB0aGUgc2VudGVuY2UuICBJ ZiB5b3UgcmVwbGFjZSDigJxpbnRlcmZhY2VzIGFuZOKAnSB3aXRoIOKAnGludGVyZmFjZXM74oCd IGl0IGZpeGVzIHRoYXQgcHJvYmxlbSBlYXNpbHkuDQoNCiAgIHVzaW5nIHByZS1jb25maWd1cmVk IGhvc3RuYW1lcyBvciBbUkZDNjc2M10gRE5TLVNELg0KDQpUaGUgY2l0YXRpb24gc2hvdWxkIGdv IGFmdGVyIOKAnEROUy1TROKAnS4NCg0K4oCUIFNlY3Rpb24gMi4xIOKAlA0KDQogICAtICBGaXJt d2FyZSBJbWFnZTogVGhlIGZpcm13YXJlIGltYWdlLCBvciBpbWFnZSwgaXMgYSBiaW5hcnkNCg0K VGhlIOKAnG9yIGltYWdl4oCdIHNlZW1zIG9kZCB0aGVyZS4gIE1heWJlIGxpa2UgdGhpcz86DQoN Ck5FVw0KICAgLSAgRmlybXdhcmUgSW1hZ2U6IFRoZSBmaXJtd2FyZSBpbWFnZSwgb3Igc2ltcGx5 IHRoZSDigJxpbWFnZeKAnSwNCiAgICAgICBpcyBhIGJpbmFyeQ0KRU5EDQoNCuKAlCBTZWN0aW9u IDIuMyDigJQNCg0KICAgICAgVGhlIGRlcGxveW1lbnQgb2Ygc3RhdHVzIHRyYWNrZXJzIGlzIGZs ZXhpYmxlIGFuZCBtYXkNCiAgICAgIGJlIGZvdW5kIGF0DQogICAgICBjbG91ZC1iYXNlZCBzZXJ2 ZXJzLCBvbi1wcmVtaXNlIHNlcnZlcnMsIG9yIG1heSBiZSBlbWJlZGRlZCBpbg0KICAgICAgZWRn ZSBjb21wdXRpbmcgZGV2aWNlcy4NCg0KKE9kZCBsaW5lLWJyZWFrIGhlcmUuLi4pDQpOaXQ6IHRo ZSBsaXN0IGlzIG5vdCBwYXJhbGxlbCwgYW5kIHRoZSBpbnRybyBkb2VzbnQgcmVhZCByaWdodC4g IFRyeSB0aGlzPzoNCg0KTkVXDQogICAgICBUaGUgZGVwbG95bWVudCBvZiBzdGF0dXMgdHJhY2tl cnMgaXMgZmxleGlibGU6IHRoZXkgbWF5DQogICAgICBiZSBmb3VuZCBhdCBjbG91ZC1iYXNlZCBz ZXJ2ZXJzIG9yIG9uLXByZW1pc2Ugc2VydmVycywNCiAgICAgIG9yIHRoZXkgbWF5IGJlIGVtYmVk ZGVkIGluIGVkZ2UgY29tcHV0aW5nIGRldmljZXMuDQpFTkQNCg0K4oCUIFNlY3Rpb24gMyDigJQN Cg0KICAgaW1hZ2VzIHRvIHRoZSBmaXJtd2FyZSBzZXJ2ZXIgYW5kIHRvIGluaXRpYXRlIGFuIHVw ZGF0ZSBoaW0tIG9yDQogICBoZXJzZWxmLg0KDQpOaXQ6IEkgc3VnZ2VzdCBhdm9pZGluZyB0aGUg YXdrd2FyZG5lc3MgYnkgc2F5aW5nIOKAnGFuZCB0byBpbml0aWF0ZSBhbiB1cGRhdGUgZGlyZWN0 bHku4oCdDQoNCiAgIEFzIGEgZmlyc3Qgc3RlcCBpbiB0aGUgZmlybXdhcmUgdXBkYXRlIHByb2Nl c3MsIHRoZSBzdGF0dXMgdHJhY2tlcg0KICAgY2xpZW50IG5lZWRzIHRvIGJlIG1hZGUgYXdhcmUg b2YgdGhlIGF2YWlsYWJpbGl0eSBvZiBhIG5ldyBmaXJtd2FyZQ0KICAgdXBkYXRlIGJ5IHRoZSBz dGF0dXMgdHJhY2tlciBzZXJ2ZXIuDQoNCk5pdDogcGFzc2l2ZSB2b2ljZSBtYWtlcyB0aGlzIG1v cmUgYXdrd2FyZCB0aGFuIGl0IG5lZWRzIHRvIGJlLCBlc3BlY2lhbGx5IGFzIHlvdSBoYXZlIGEg Y2xlYXIgc3ViamVjdCBhbHJlYWR5ICh0aGUgc2VydmVyKS4gIFdoeSBub3QgbWFrZSBpdCBhY3Rp dmU/Og0KDQpORVcNCiAgIEFzIGEgZmlyc3Qgc3RlcCBpbiB0aGUgZmlybXdhcmUgdXBkYXRlIHBy b2Nlc3MsIHRoZSBzdGF0dXMgdHJhY2tlcg0KICAgc2VydmVyIG5lZWRzIHRvIGluZm9ybSB0aGUg c3RhdHVzIHRyYWNrZXIgY2xpZW50IHRoYXQgYSBuZXcgZmlybXdhcmUNCiAgIHVwZGF0ZSBpcyBh dmFpbGFibGUuDQpFTkQNCg0KICAgLSAgVXNpbmcgYSBoeWJyaWQgYXBwcm9hY2ggdGhlIHNlcnZl ci1zaWRlIG9mIHRoZSBzdGF0dXMgdHJhY2tlcg0KICAgICAgcHVzaGVzIG5vdGlmaWNhdGlvbnMg b2YgYXZhaWxhYmlsaXR5IG9mIGFuIHVwZGF0ZSB0byB0aGUgY2xpZW50DQogICAgICBzaWRlIGFu ZCByZXF1ZXN0cyB0aGUgZmlybXdhcmUgY29uc3VtZXIgdG8gcHVsbCB0aGUgbWFuaWZlc3QgYW5k DQogICAgICB0aGUgZmlybXdhcmUgaW1hZ2UgZnJvbSB0aGUgZmlybXdhcmUgc2VydmVyLg0KDQpB cyB3cml0dGVuLCB0aGlzIGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgdGhlIHNlcnZlci1pbml0aWF0 ZWQgc2NlbmFyaW8uICBJbiBib3RoIGNhc2VzLCB0aGUgc2VydmVyIHRlbGxzIHRoZSBjbGllbnQg dGhhdCBhbiB1cGRhdGUgaXMgYXZhaWxhYmxlLCBhbmQgdGhlIGZpcm13YXJlIGNvbnN1bWVyIGZl dGNoZXMgdGhlIG1hbmlmZXN0IGFuZCBpbWFnZS4gIFdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgbWVh bnQgdG8gYmU/ICBEbyBvbmUgb3IgYm90aCBvZiB0aGUgZGVzY3JpcHRpb25zIG5lZWQgdG8gYmUg dHdlYWtlZD8gIChJ4oCZbSBndWVzc2luZyB0aGF0IHRoZSBzZXJ2ZXItaW5pdGlhdGVkIGRlc2Ny aXB0aW9uIHNob3VsZCBiZSBjaGFuZ2VkIHRvIHNheSB0aGF0IHRoZSBzZXJ2ZXIgcHVzaGVzIHRo ZSBtYW5pZmVzdCBhbmQgaW1hZ2UsIHJhdGhlciB0aGFuIHdhaXRpbmcgZm9yIHRoZSBjbGllbnQg dG8gZmV0Y2ggaXQuLi4geWVzPykNCg0KICAgSWYgdGhlIGZpcm13YXJlIGNvbnN1bWVyIGhhcyBk b3dubG9hZGVkIGEgbmV3IGZpcm13YXJlIGltYWdlIGFuZCBpcw0KICAgcmVhZHkgdG8gaW5zdGFs bCBpdCwgdG8gaW5pdGlhdGUgdGhlIGluc3RhbGxhdGlvbiwgaXQgbWF5IC0gZWl0aGVyDQogICBu ZWVkIHRvIHdhaXQgZm9yIGEgdHJpZ2dlciBmcm9tIHRoZSBzdGF0dXMgdHJhY2tlciwgLSBvciB0 cmlnZ2VyIHRoZQ0KICAgdXBkYXRlIGF1dG9tYXRpY2FsbHksIC0gb3IgZ28gdGhyb3VnaCBhIG1v cmUgY29tcGxleCBkZWNpc2lvbiBtYWtpbmcNCiAgIHByb2Nlc3MgdG8gZGV0ZXJtaW5lIHRoZSBh cHByb3ByaWF0ZSB0aW1pbmcgZm9yIGFuIHVwZGF0ZS4NCg0KQXJlIHRob3NlIGRhc2hlcyBtZWFu dCB0byBiZSBidWxsZXRzIGluIGEgbGlzdCwgYW5kIHNvIGlzIHRoaXMgYSBmb3JtYXR0aW5nIGds aXRjaD8NCg0KICAgRGV2aWNlcw0KICAgbXVzdCBub3QgZmFpbCB3aGVuIGEgZGlzcnVwdGlvbiBv Y2N1cnMgZHVyaW5nIHRoZSB1cGRhdGUgcHJvY2Vzcy4NCiAgIEZvciBleGFtcGxlLCBhIHBvd2Vy IGZhaWx1cmUgb3IgbmV0d29yayBkaXNydXB0aW9uIGR1cmluZyB0aGUgdXBkYXRlDQogICBwcm9j ZXNzIG11c3Qgbm90IGNhdXNlIHRoZSBkZXZpY2UgdG8gZmFpbC4NCg0KTml0OiB3aHkgbm90IG1l cmdlIHRoZXNlIHR3byBzZW50ZW5jZXM/Og0KDQpORVcNCiAgIERldmljZXMNCiAgIG11c3Qgbm90 IGZhaWwgd2hlbiBhIGRpc3J1cHRpb24sIHN1Y2ggYXMgYSBwb3dlciBmYWlsdXJlIG9yIG5ldHdv cmsNCiAgIGludGVycnVwdGlvbiwgb2NjdXJzIGR1cmluZyB0aGUgdXBkYXRlIHByb2Nlc3MuDQpF TkQNCg0K4oCUIFNlY3Rpb24gNC4xIOKAlA0KDQogICAtICBUaGUgYm9vdGxvYWRlciBuZWVkcyB0 byBmZXRjaCB0aGUgbWFuaWZlc3QgKG9yIG1hbmlmZXN0LWFsaWtlDQogICAgICBoZWFkZXJzKSBm cm9tIG5vbnZvbGF0aWxlIHN0b3JhZ2UNCg0KV2hhdCBhcmUg4oCcbWFuaWZlc3QtYWxpa2UgaGVh ZGVyc+KAnT8NCg0KICAgICAgVGhpcyBhbGxvd3MgdG8gc2hhcmUNCiAgICAgIGluZm9ybWF0aW9u IGFib3V0IHRoZSBjdXJyZW50IGZpcm13YXJlIHZlcnNpb24NCg0K4oCcQWxsb3dzIHRvIHNoYXJl 4oCdIGRvZXNu4oCZdCB3b3JrIGluIEVuZ2xpc2g6IHlvdSBuZWVkIGEgc3ViamVjdCwg4oCcYWxs b3dzIDxzdWJqZWN0PiB0byBzaGFyZSA8b2JqZWN0PuKAnS4gIElmIHlvdSBkb27igJl0IGhhdmUg YSBzdWJqZWN0LCB5b3UgY2FuIHNheSDigJxhbGxvd3MgdGhlIHNoYXJpbmcgb2YgaW5mb3JtYXRp b24uLi7igJ0uDQoNCuKAlCBTZWN0aW9uIDYg4oCUDQoNCiAgIEEgbWFuaWZlc3QgbWF5IG5vdCBv bmx5IGJlIHVzZWQgdG8gcHJvdGVjdCBmaXJtd2FyZSBpbWFnZXMgYnV0IGFsc28NCiAgIGNvbmZp Z3VyYXRpb24gZGF0YSBzdWNoIGFzIG5ldHdvcmsgY3JlZGVudGlhbHMNCg0KU2ltaWxhciB0byBh IGNvbW1lbnQgYWJvdmUsIHRoaXMgaGFzIOKAnG5vdCBvbmx54oCdIG1pc3BsYWNlZDoNCg0KTkVX DQogICBBIG1hbmlmZXN0IG1heSBiZSB1c2VkIHRvIHByb3RlY3Qgbm90IG9ubHkgZmlybXdhcmUg aW1hZ2VzIGJ1dCBhbHNvDQogICBjb25maWd1cmF0aW9uIGRhdGEgc3VjaCBhcyBuZXR3b3JrIGNy ZWRlbnRpYWxzIEVORA0KDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0K From nobody Thu Nov 19 22:27:55 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB73A1912; Thu, 19 Nov 2020 22:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=4a6ZKG+k; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=4a6ZKG+k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUJ6r5XhYCBr; Thu, 19 Nov 2020 22:27:46 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2076.outbound.protection.outlook.com [40.107.22.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69ACC3A1908; Thu, 19 Nov 2020 22:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5+SG28QQivxo4qF3M4mIlzze2Mv2BnT+T/9Dbp1bNo0=; b=4a6ZKG+k6S64P74iOWpw+EtdkZeug9R4oTgV/qNXRqrCn0iqOPIFW1hauwE2ur2u0GNl8SnL2eiVNqAomh10n4QsvIH0DFMv3DmVSgS1ONQxeRfmAV/PRjW8ntiQDbOWV0drF9JH7i0QTm2MJvqdNpCK3/ln9qm3T7Au1pBzhrU= Received: from AM6P194CA0012.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:90::25) by VE1PR08MB5245.eurprd08.prod.outlook.com (2603:10a6:803:10a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Fri, 20 Nov 2020 06:27:41 +0000 Received: from VE1EUR03FT018.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:90:cafe::61) by AM6P194CA0012.outlook.office365.com (2603:10a6:209:90::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 06:27:41 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT018.mail.protection.outlook.com (10.152.18.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 06:27:40 +0000 Received: ("Tessian outbound fcd5bc555ddc:v71"); Fri, 20 Nov 2020 06:27:40 +0000 X-CR-MTA-TID: 64aa7808 Received: from 7787a7b07ac1.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 573EEFE0-A321-4B17-BD0A-AFE897270079.1; Fri, 20 Nov 2020 06:27:35 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7787a7b07ac1.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 20 Nov 2020 06:27:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SErsAA8qMExbJd5Tm5MKKCX9yywXAYltmUXiPqEJhCwWZ2KPgLQS5qqu006z2Rewp7vc9sNBwYUTUDi9th+7FVvb8iOvLTpLoBZPJJbxZtCMFJQkwlT87dUL/XDKf7uviaF/YspHywRhi7DbavBtQ4/C29k4bo0htGUX92B8tW9PUmHrxHfN2BcOCYKTq6MQgquMBeu9hIDBJztyuio/XmGBFEI+rD7RYjB1OIJ0QFiMwcACcSW8FBjOosv/1A5YZ56K2OHOlSCQDP+v82zApVYThgB/xbwvSeiGs1Q2PuLfqfnNSILOSWnT3iR1B0v9C9ZoalhmM2LY6C7nXxr/yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5+SG28QQivxo4qF3M4mIlzze2Mv2BnT+T/9Dbp1bNo0=; b=I6pdcJiXOf7YIfKj1ibN+89Wko+6MjonTrPR6VvWuKA/OxU3VfXU+malxgQ2dWJO5jK7lGMqPTQGJHs/72DIHe5lMaxasYaZL3OxmUzdMt0s5+rtVxqb+hVJW+NkYYnlwis69+C5eXyx82mIUxOS/Dhmf+zsQdiCE3Z7nOohvO7FMViC8g/k23qvnzNXWow6OHJ7IvFJCjfW9Ws/bQN0T3wv7WfpIqSGUn6wrmTlkI1L9EXxaTvSd9iKfOYU+Tn/Vf7MsR7YyFodpf9WYIdtFcb67qP1g/y6RT650KHM4wRKu9VyC2xcHHQ1fN2CNB1bmQAaz/XEOUZiEmUVQJ3YwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5+SG28QQivxo4qF3M4mIlzze2Mv2BnT+T/9Dbp1bNo0=; b=4a6ZKG+k6S64P74iOWpw+EtdkZeug9R4oTgV/qNXRqrCn0iqOPIFW1hauwE2ur2u0GNl8SnL2eiVNqAomh10n4QsvIH0DFMv3DmVSgS1ONQxeRfmAV/PRjW8ntiQDbOWV0drF9JH7i0QTm2MJvqdNpCK3/ln9qm3T7Au1pBzhrU= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM8PR08MB5810.eurprd08.prod.outlook.com (2603:10a6:20b:1d2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Fri, 20 Nov 2020 06:27:32 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48%7]) with mapi id 15.20.3564.028; Fri, 20 Nov 2020 06:27:32 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , Brendan Moran CC: Russ Housley , "suit-chairs@ietf.org" , suit , The IESG , "draft-ietf-suit-architecture@ietf.org" Thread-Topic: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) Thread-Index: AQHWs1eESdPahh/YtU6TGxVrOWgGpKnOhzwAgADbPACAAT9/UA== Date: Fri, 20 Nov 2020 06:27:32 +0000 Message-ID: References: <160456913386.24093.10722400425795162498@ietfa.amsl.com> <20201119111024.GD39170@kduck.mit.edu> In-Reply-To: <20201119111024.GD39170@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 6252368010759143AA16C492AEFE47E5.0 x-checkrecipientchecked: true Authentication-Results-Original: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.118.246] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 538c4582-9998-4599-f5a3-08d88d1d6211 x-ms-traffictypediagnostic: AM8PR08MB5810:|VE1PR08MB5245: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:3513;OLM:3513; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: boOzynlx45w+h+IUbYS3AZsaFGWPvntGL5tRFW0Lilx9uz+af32d8PlDUnLjPUPdg5yNPMEk885mN8XwoYQ0VTUYScdYuGuWeD6Ev9OQYF6uGGQo2y+5N/ByXqLhAU6xjTPHvyc9DLxulxVTZxVSXBdMRMpQBS3UAIfSuaOfVAPugeGIPitSoYYcPks7qb51OGOjEgcxvoMHY3OudLMtTU3LXnki4OJ/fi4jmgMbUAGP/XJS0YMACVUPgCBHixVlv7zeZUIwppuCBZL1wHztqQK0R4lX/YvrXebg3iS0HwR+cz87lu4cPeZ8nRXiLrLhOkBh7fFPPzBbz8cVAQU0r7RQIGN+DmsdFbY1qC9B44lfSTapyuq1Bq9CkWRFweTt4GEv/6Od2XC1+6ec5Eyr4w== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(39840400004)(376002)(366004)(33656002)(30864003)(2906002)(966005)(6636002)(71200400001)(53546011)(6506007)(64756008)(83380400001)(478600001)(66446008)(8676002)(7696005)(8936002)(54906003)(66556008)(110136005)(26005)(86362001)(52536014)(9686003)(55016002)(76116006)(66476007)(186003)(5660300002)(316002)(66946007)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: M0ahrssdH6n6TjlgKMxVJlCqFFDYIyGyD2jDc6Iq6RrnBG/IH1p/Kdt/4WlbNBGgQ3t2d8W/+1Rr4nluhMrsT6gmD7HAF98aNFlL+xLpfZx2NOhXbtp08s+eegYyivO0cJeu9o/xSxE9laz7t5OIHJ/paxqC7qIxTuzdbVm390ntazguSqL0elOBlUUMfFVxSLRUxYDTDJK32ozCf9Y+EehBeUolKvxw6V0CBZSznj6zhbeUbUf6zZvhG2QTNQ5oEu8okrVY2LxTaNDNmaeXwI5nxHRJJoBYyuqwD5/PuzmFblIAY3I7XlQlXlsgpVbLtu8DYBGU/9IHU+s20o2hP+D0uGwT3McR7ib/6Td9LXt0uX61rYhmcevqEPb2kqzuT8ZEPCzYpq9e0NIXCoUSQFgLuNF8uwyyPhxN3Ycw2U/BjvLooFxgLNwoyhi7UlK08Z/UFc7g/DnpKxV//fE0MHqK3rKQHoswlPp0kSXFLfocfnA25t31lTCZVSSkr6JqHAz8lIHSVy5mf8C2acemjTNNIPraG4NTT4luZ1Vr7Nq95Ob0pYQkSRBnz8rb7e9j9iqxiYqNyky6OPgUclMIT38bwKe1doHxE+bJI2UOc2bTQMS01hn8xwWfxOz9WzkquM854zwR6gVOTpHM0oKKMg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5810 Original-Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT018.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d743f0cb-5d12-47bb-0551-08d88d1d5cf4 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Z6Vc2s72X182JGvI1FS5JoHknUx3FZ0E9vR2BOWC1ilWvoL45tHA6XrSORxCnEBx6qB+auNSJhDpDpZ5BVX5x/7NQXvhj9seIfk9NFBz2cqjwMbtiyq5GUpDhiRan/UWjrVwZr9ao4fcZJQdJjhcLbf+yLY86VKBuy+Vpttzje9RIMuC/Ocb0Po0eSSydwGG2ko8zVTQtMbC1vWmdWW6zl4x+xPzwGy158Ev2f4Fo677czj1XIRZKnTVbvwimVTu4SxlziWQGtKcoZ/WAhu3PG3huYRCO/4EVB9M2vTQYPLUNrHFrQheA2H8LwkSekl2HJG9D5LfSS26Hxqz6EurG31WK3YsoxyDLzpABma+/pBrejmf+y3A5PEJc1XfeBu+ODzaqei8wUv4g5I4lMxj+MwpbLf/tuCCWRaWKADKN4Kj5uW9CzVEav4rZw6jGQYt7K+gjpIbPKVagJSxSlhKgZNNPHqxmDi7VCR0k6TWkMQ= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(346002)(39840400004)(376002)(136003)(46966005)(8936002)(478600001)(70206006)(4326008)(70586007)(82310400003)(8676002)(83380400001)(54906003)(110136005)(7696005)(6636002)(186003)(47076004)(316002)(52536014)(86362001)(966005)(450100002)(356005)(55016002)(5660300002)(336012)(2906002)(6506007)(30864003)(26005)(81166007)(53546011)(33656002)(9686003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2020 06:27:40.8378 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 538c4582-9998-4599-f5a3-08d88d1d6211 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT018.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5245 Archived-At: Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 06:27:49 -0000 Hi Ben Thanks for your review and for your PR with the proposed changes. I have created PRs to address some of your remarks: https://github.com/suit-wg/architecture/pull/16 https://github.com/suit-wg/architecture/pull/17 I have addressed the remark below in PR #16: " Section 1 otherwise difficult. Firmware updates for IoT devices are expected to work automatically, i.e. without user involvement. Conversely, IoT devices are expected to account for user preferences and consent when scheduling updates. Automatic I can't quite tell if the "Conversely" case is intending to refer to IoT or non-IoT devices. " The remark below is addressed in PR#16: " The firmware update process has to ensure that - The firmware image is authenticated and integrity protected. [...] - The firmware image can be confidentiality protected so that attempts by an adversary to recover the plaintext binary can be [...] Perhaps it's just because Bob Briscoe's comments are fresh in my mind, but there seems to be something of a mismatch across these texts -- we "have to ensure" that the firmware *is* authenticated and integrity protected, but only that the image *can be* confidentiality protected. Is it really the case that we can ensure that an update process *can be* confidentiality protected, or is the confidentiality requirement more of a requirement on the architecture than on actual deployment? " The comment below is addressed in PR#17: " While the IETF standardization work has been focused on the manifest format, a fully interoperable solution needs more than a standardized manifest. For example, protocols for transferring firmware images and manifests to the device need to be available as well as the status tracker functionality. Devices also require a mechanism to discover the status tracker(s) and/or firmware servers, for example using pre-configured hostnames or [RFC6763] DNS-SD. These building blocks have been developed by various organizations under the umbrella of an IoT device management solution. The LwM2M protocol is one IoT device management protocol. We might put some forward references to things we do cover (like status tracker(s)), and a reference for LwM2M as well. " I did not make changes regarding this comment because I couldn't find text = that claimed that the status tracker on the device is uncommon. " Section 3 Hence, the following components are necessary on a device for a firmware update solution: [...] - a status tracker. Earlier we said that having the status tracker on the device was fairly uncommon. " The issue about post-quantum crypto is being discussed separately. Regarding the comment below I still have to think about how to best address= it. Flash memory wears out but there are different flash memories and there are= flash controllers trying to prevent uneven wear-out. I have to think about what the draft should discuss regarding the implicati= ons of execute in place (XIP) with respect to the wear of flash memory. " Does the XIP case mean that repeated firmware updates would have potential to cause undue wear on the fixed flash cells that hold the firmware image? If so, this might be noted in the security considerations. " Ciao Hannes -----Original Message----- From: Suit On Behalf Of Benjamin Kaduk Sent: Thursday, November 19, 2020 12:10 PM To: Brendan Moran Cc: Russ Housley ; suit-chairs@ietf.org; suit ; The IESG ; draft-ietf-suit-architecture@ietf.org Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-archit= ecture-14: (with COMMENT) Hi Brendan, Thanks for the extra reference and discussion about the timescale estimates= for quantum computers and integer factorization. (And for accepting most = of my other comments.) I see now how the factorization-by-annealing refere= nce was intended to be used, and had not been paying close enough attention= to know the 5640-qbit and doubling-every-two-years numbers for D-Wave. If I was going to suggest a change to the text, it would be quite small, pe= rhaps something like "based on current research [quantum-factorization] and= the trend in quantum annealing capacity". Thanks again, Ben On Wed, Nov 18, 2020 at 10:05:44PM +0000, Brendan Moran wrote: > We will take on board the majority of these comments. > > WRT the PQC time horizon, quantum annealing attacks on RSA are dependent = commercial quantum annealers. > > The paper in nature shows the factorisation of 376,289 in 94 qubits. In f= act, other researchers have factored 1,005,973 with only 89 qubits [1]. Wit= h this second algorithm, characterised as O(log^2(N)), RSA-768 would requir= e 147,454 qubits. D-Wave has shipped quantum computers with 5640 qubits alr= eady. They have a historical average of doubling the number of qubits every= two years. Based on this trajectory, they should be shipping a quantum com= puter that can break RSA-768 in approximately 2030 (log_2(147454/5640)) =3D= 4.7 =3D> 9.4 years. RSA-2048, then, would be broken between 2 and 4 years = later, and RSA-4096 a mere 2 years after that. > > This is a naive analysis. However, it is intended to show that a scalable= general purpose quantum computer is not the only threat to current cryptog= raphic techniques, that the time horizon is not long, and that urgent actio= n is required to ensure that devices with long lifetimes account for EITHER= cryptographic agility or quantum safety, preferably the latter, since quan= tum safe algorithms require much more data than classical asymmetric crypto= and, therefore, require extra considerations, particularly when used in co= nstrained IoT. > > Obviously, the hole in this analysis is that RSA is not common in IoT. I = have not yet found equivalent research that shows how a quantum annealer co= uld attack ECDSA or EDDSA. I assume that there are research teams working o= n this. We should prepare ourselves for the potential of that particular re= velation. > > We have not gone into this detail in the architecture because it seems bo= th orthogonal to the general discussion in the architecture, extremely time= -sensitive, and extremely algorithm-sensitive. It will be an irrelevant pre= diction and analysis within a handful of years. > > Best Regards, > Brendan > > [1] https://link.springer.com/article/10.1007/s11433-018-9307-1 > > > > On 5 Nov 2020, at 09:38, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-suit-architecture-14: No Objection > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ > > > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Does the XIP case mean that repeated firmware updates would have > > potential to cause undue wear on the fixed flash cells that hold the > > firmware image? If so, this might be noted in the security > > considerations. > > > > I am not sure that I have fully digested Bob Briscoe's detailed > > review comments, but it seems like we may want to continue to > > reflect on which portions of the architecture will be optional to > > implement, and how we might indicate that in the document. > > > > I also made a pull request for some editorial nits at > > https://github.com/suit-wg/architecture/pull/15 . > > > > Section 1 > > > > otherwise difficult. Firmware updates > > for IoT devices are expected to work automatically, i.e. without user > > involvement. Conversely, IoT devices are expected to account for > > user preferences and consent when scheduling updates. Automatic > > > > I can't quite tell if the "Conversely" case is intending to refer to > > IoT or non-IoT devices. > > > > The firmware update process has to ensure that > > > > - The firmware image is authenticated and integrity protected. > > [...] > > > > - The firmware image can be confidentiality protected so that > > attempts by an adversary to recover the plaintext binary can be > > [...] > > > > Perhaps it's just because Bob Briscoe's comments are fresh in my > > mind, but there seems to be something of a mismatch across these > > texts -- we "have to ensure" that the firmware *is* authenticated > > and integrity protected, but only that the image *can be* confidentiali= ty protected. > > Is it really the case that we can ensure that an update process *can > > be* confidentiality protected, or is the confidentiality requirement > > more of a requirement on the architecture than on actual deployment? > > > > While the IETF standardization work has been focused on the manifest > > format, a fully interoperable solution needs more than a standardized > > manifest. For example, protocols for transferring firmware images > > and manifests to the device need to be available as well as the > > status tracker functionality. Devices also require a mechanism to > > discover the status tracker(s) and/or firmware servers, for example > > using pre-configured hostnames or [RFC6763] DNS-SD. These building > > blocks have been developed by various organizations under the > > umbrella of an IoT device management solution. The LwM2M protocol is > > one IoT device management protocol. > > > > We might put some forward references to things we do cover (like > > status tracker(s)), and a reference for LwM2M as well. > > > > Section 3 > > > > Hence, the following components are necessary on a device for a > > firmware update solution: > > [...] > > - a status tracker. > > > > Earlier we said that having the status tracker on the device was > > fairly uncommon. > > > > Section 7 > > > > time horizon for quantum-accelerated key extraction. The worst-case > > estimate, at time of writing, for the time horizon to key extraction > > with quantum acceleration is approximately 2030, based on current > > research [quantum-factorization]. > > > > I'm not sure that I see how the reference suports the "approximately > > 2030" statement. > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. _______________________________________________ Suit mailing list Suit@ietf.org https://www.ietf.org/mailman/listinfo/suit IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Thu Nov 19 22:57:45 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4233A1971; Thu, 19 Nov 2020 22:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyiQCGPVTy8U; Thu, 19 Nov 2020 22:57:39 -0800 (PST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97153A196D; Thu, 19 Nov 2020 22:57:38 -0800 (PST) Received: by mail-vs1-f50.google.com with SMTP id h185so4498031vsc.3; Thu, 19 Nov 2020 22:57:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WHlg1VFPvlCtN+ZrQM8SHTkoFWkYe3kn966Ydmgl3d8=; b=j+4oP+r3MK+CMpiQ30MINa7KjzfKsAIQKASXiavzIvSQrYSkSlGBAXnZi0/bW10K7m UpZzNUiWplWGBbIIXTq7KH5U59Vubnau6WRyoL4iJbN5Vj/ni1lxQOLk0wWNoN61z4H6 R75LC5av2Ii5s4StZEXLsDVrBnf2SY5+Odt77rFUf9ZJ1ea4Tczl+bufuJgYA9MOLQ61 7xPtYoRlYwykZ5BgM/SWXrF7uP/tHasSP253jT8w83Ae1HuRwa6qsWTGbbnvu0fCfi4r RUYqOzXxjMnln4k8vHdWNOzF2Mcsfefc3OJqq2lTn1D4wLGMKZuXJHkerboijdnAhCqy Gswg== X-Gm-Message-State: AOAM532oZckWddLNykthXd1XTq4gKhdx+NtoehkKhZgODwnvHfKo1mzC l0fDxcsZzTb22yHd/xS+MEvu5OWhf3yvG9HUI7w= X-Google-Smtp-Source: ABdhPJw1S+c5NxTm5dmOfIUJLwfF3Cy7KZ2Y0LgzuXqt/Or+7YHKKOqs5V1bNIfArlJ3OtyN8RsNmnF6jmx2nr/P148= X-Received: by 2002:a67:f05:: with SMTP id 5mr11017804vsp.39.1605855457667; Thu, 19 Nov 2020 22:57:37 -0800 (PST) MIME-Version: 1.0 References: <160425219933.2164.12165140117377106860@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Fri, 20 Nov 2020 01:57:25 -0500 Message-ID: To: Hannes Tschofenig Cc: The IESG , "draft-ietf-suit-architecture@ietf.org" , "suit-chairs@ietf.org" , "suit@ietf.org" , Russ Housley Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Suit] Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 06:57:41 -0000 Thanks, Hannes! Barry On Fri, Nov 20, 2020 at 1:13 AM Hannes Tschofenig wrote: > > Hi Barry, > > Thanks for your review. I have incorporated the suggested changes in this= PR: https://github.com/suit-wg/architecture/pull/18 > > Ciao > Hannes > > > -----Original Message----- > From: Barry Leiba via Datatracker > Sent: Sunday, November 1, 2020 6:37 PM > To: The IESG > Cc: draft-ietf-suit-architecture@ietf.org; suit-chairs@ietf.org; suit@iet= f.org; Russ Housley ; housley@vigilsec.com > Subject: Barry Leiba's No Objection on draft-ietf-suit-architecture-14: (= with COMMENT) > > Barry Leiba has entered the following ballot position for > draft-ietf-suit-architecture-14: No Objection > > When responding, please keep the subject line intact and reply to all ema= il addresses included in the To and CC lines. (Feel free to cut this introd= uctory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Nice work on this; thanks. I have a bunch of comments, but all minor. > > =E2=80=94 Section 1 =E2=80=94 > > Firmware updates can help to fix security vulnerabilities and are > considered to be an important building block in securing IoT devices. > > Nit: =E2=80=9Cfirmware updates=E2=80=9D is plural, and =E2=80=9Cbuilding = block=E2=80=9D is singular. I think it=E2=80=99s actually *doing* the upda= tes that=E2=80=99s the building block, not he updates themselves. And you = can just make the statement, without =E2=80=9Care considered=E2=80=9D. > How do you like this version?: > > NEW > Firmware updates can help to fix security vulnerabilities, and > performing updates is an important building block in securing > IoT devices. > END > > Due to rising concerns about insecure IoT devices the Internet > Architecture Board (IAB) organized a 'Workshop on Internet of Things > (IoT) Software Update (IOTSU)', which took place at Trinity College > Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at > the bigger picture. A report about this workshop can be found at > [RFC8240]. The workshop revealed a number of challenges for > developers and led to the formation of the IETF Software Updates for > Internet of Things (SUIT) working group. > > The details of when and where the workshop happened isn=E2=80=99t importa= nt here, and it=E2=80=99s rigt up front in 8240 anyway. I suggest trimming= that, because the important part is pointing people to the worshop report = and saying what=E2=80=99s in the next sentence about the formation of the S= UIT WG. > > NEW > Due to rising concerns about insecure IoT devices the Internet > Architecture Board (IAB) organized a 'Workshop on Internet of Things > (IoT) Software Update (IOTSU)' [RFC8240] to take a look at > the bigger picture. The workshop revealed a number of challenges for > developers and led to the formation of the IETF Software Updates for > Internet of Things (SUIT) working group. > END > > Firmware updates are not only done to fix bugs, but they can also add > new functionality, and re-configure > > Grammar nit: =E2=80=9CFirmware updates are done not only to fix bugs, but= also to add new functionality and to reconfigure=E2=80=9D > > Unlike higher end devices, like laptops and desktop PCs, many > IoT devices do not have user interfaces and support for unattended > updates is, therefore, essential for the design of a practical > > My first reading of this was that =E2=80=9Cmany IoT devices do not have u= ser interfaces and support for unattended updates.=E2=80=9D I had to read = it again to correctly interpret the sentence. If you replace =E2=80=9Cinte= rfaces and=E2=80=9D with =E2=80=9Cinterfaces;=E2=80=9D it fixes that proble= m easily. > > using pre-configured hostnames or [RFC6763] DNS-SD. > > The citation should go after =E2=80=9CDNS-SD=E2=80=9D. > > =E2=80=94 Section 2.1 =E2=80=94 > > - Firmware Image: The firmware image, or image, is a binary > > The =E2=80=9Cor image=E2=80=9D seems odd there. Maybe like this?: > > NEW > - Firmware Image: The firmware image, or simply the =E2=80=9Cimage=E2= =80=9D, > is a binary > END > > =E2=80=94 Section 2.3 =E2=80=94 > > The deployment of status trackers is flexible and may > be found at > cloud-based servers, on-premise servers, or may be embedded in > edge computing devices. > > (Odd line-break here...) > Nit: the list is not parallel, and the intro doesnt read right. Try this= ?: > > NEW > The deployment of status trackers is flexible: they may > be found at cloud-based servers or on-premise servers, > or they may be embedded in edge computing devices. > END > > =E2=80=94 Section 3 =E2=80=94 > > images to the firmware server and to initiate an update him- or > herself. > > Nit: I suggest avoiding the awkwardness by saying =E2=80=9Cand to initiat= e an update directly.=E2=80=9D > > As a first step in the firmware update process, the status tracker > client needs to be made aware of the availability of a new firmware > update by the status tracker server. > > Nit: passive voice makes this more awkward than it needs to be, especiall= y as you have a clear subject already (the server). Why not make it active= ?: > > NEW > As a first step in the firmware update process, the status tracker > server needs to inform the status tracker client that a new firmware > update is available. > END > > - Using a hybrid approach the server-side of the status tracker > pushes notifications of availability of an update to the client > side and requests the firmware consumer to pull the manifest and > the firmware image from the firmware server. > > As written, this is exactly the same as the server-initiated scenario. I= n both cases, the server tells the client that an update is available, and = the firmware consumer fetches the manifest and image. What is the differen= ce meant to be? Do one or both of the descriptions need to be tweaked? (I= =E2=80=99m guessing that the server-initiated description should be changed= to say that the server pushes the manifest and image, rather than waiting = for the client to fetch it... yes?) > > If the firmware consumer has downloaded a new firmware image and is > ready to install it, to initiate the installation, it may - either > need to wait for a trigger from the status tracker, - or trigger the > update automatically, - or go through a more complex decision making > process to determine the appropriate timing for an update. > > Are those dashes meant to be bullets in a list, and so is this a formatti= ng glitch? > > Devices > must not fail when a disruption occurs during the update process. > For example, a power failure or network disruption during the update > process must not cause the device to fail. > > Nit: why not merge these two sentences?: > > NEW > Devices > must not fail when a disruption, such as a power failure or network > interruption, occurs during the update process. > END > > =E2=80=94 Section 4.1 =E2=80=94 > > - The bootloader needs to fetch the manifest (or manifest-alike > headers) from nonvolatile storage > > What are =E2=80=9Cmanifest-alike headers=E2=80=9D? > > This allows to share > information about the current firmware version > > =E2=80=9CAllows to share=E2=80=9D doesn=E2=80=99t work in English: you ne= ed a subject, =E2=80=9Callows to share =E2=80=9D. If you= don=E2=80=99t have a subject, you can say =E2=80=9Callows the sharing of i= nformation...=E2=80=9D. > > =E2=80=94 Section 6 =E2=80=94 > > A manifest may not only be used to protect firmware images but also > configuration data such as network credentials > > Similar to a comment above, this has =E2=80=9Cnot only=E2=80=9D misplaced= : > > NEW > A manifest may be used to protect not only firmware images but also > configuration data such as network credentials END > > > > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. From nobody Thu Nov 19 23:19:15 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086793A1996; Thu, 19 Nov 2020 23:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=UDNNxxvd; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=UDNNxxvd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwM1bRiH1muP; Thu, 19 Nov 2020 23:19:10 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30072.outbound.protection.outlook.com [40.107.3.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314463A1993; Thu, 19 Nov 2020 23:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8D/5Mc8XrfVvrnD2trcED0Srd0a1+0va8hqhtAtJVCA=; b=UDNNxxvdGhIEfkkFV8viLmjRIc5TrJ2njizY1ZDMcdFey0BCPTCwL1okjzoLuewSzkkn5yvsKHpl6MXOFfpH24h0RaMURdYSYnJYbW0KRk4R1MeKcWMvcZmQnLHa23jwnjaF+pAAncbH831eWeurZLbeZzXRwTEVCdAMhfxpah0= Received: from AM6PR10CA0076.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::17) by VE1PR08MB5839.eurprd08.prod.outlook.com (2603:10a6:800:1a0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Fri, 20 Nov 2020 07:19:06 +0000 Received: from VE1EUR03FT020.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8c:cafe::10) by AM6PR10CA0076.outlook.office365.com (2603:10a6:209:8c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 07:19:05 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT020.mail.protection.outlook.com (10.152.18.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 07:19:05 +0000 Received: ("Tessian outbound fcd5bc555ddc:v71"); Fri, 20 Nov 2020 07:19:04 +0000 X-CR-MTA-TID: 64aa7808 Received: from d72e19e8b05c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C86E7EAD-9046-4F1A-ACBE-EC8082C2FF9C.1; Fri, 20 Nov 2020 07:18:59 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d72e19e8b05c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 20 Nov 2020 07:18:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OjhnYXKC+xWUbizhxqmhCpEycD4k4eXDujZ8AcDqHpBm2/FSi0f7JfRCPfgApYzuyxNp2PrkbIV+SaQToG576TUwa9oa7r+KDOltE9qiPvRPwCYaDCAJDOhWdy57prw5uzeu2bmUfyRzhLJu1ybNQpF3kb+NgWxrbpaQPmEcHw9ps3B0gS0oFddvVO+Py/VlMmnhZ1XnKZXTeAhJmArdN8x03HCcdoDZEJ1ykKEq7SxEdQAKCyaRUZa4unj0jb6viJewYNTzZaJ/bjPrR6UKIhEkiAILrWgjwwS3b7xW2bTEhxkkPBbORLghthNny24oHVhEYnkSJgilDMK+iuBx1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8D/5Mc8XrfVvrnD2trcED0Srd0a1+0va8hqhtAtJVCA=; b=ASvhEO51LQmjfaZnxCaTqQzXkw+CYO6dbjWHqW/+bwTz12NVD15ZuxjGZpzX9Jp8YrjdLQMuBhaDvTDs/Ncn6TAmMeSGsNebL9mOdaB4NmFs/lH158pnopRk2ncVIE3BqNK5EMa6EALAXNv3FxIxWg1DC50uUhSBjBZMU+bdt8aJXXDYwH1CjApzJQlCd8MtYIefLmqxQjn0iq/P+2iAyyioJQ0CQTYxJvKR6big2knJnWMPGC1sGVBmXV7XmSfG76HAU9vXS51PStil2KCNdtHg6/d6W+sebKpfZnXLlgNciQn1cd7nWFMhwJrZ5v7P/MflrfON9JJnVer0+TREPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8D/5Mc8XrfVvrnD2trcED0Srd0a1+0va8hqhtAtJVCA=; b=UDNNxxvdGhIEfkkFV8viLmjRIc5TrJ2njizY1ZDMcdFey0BCPTCwL1okjzoLuewSzkkn5yvsKHpl6MXOFfpH24h0RaMURdYSYnJYbW0KRk4R1MeKcWMvcZmQnLHa23jwnjaF+pAAncbH831eWeurZLbeZzXRwTEVCdAMhfxpah0= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM4PR0802MB2241.eurprd08.prod.outlook.com (2603:10a6:200:5e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Fri, 20 Nov 2020 07:18:57 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::a80c:38e:8da2:8b48%7]) with mapi id 15.20.3564.028; Fri, 20 Nov 2020 07:18:57 +0000 From: Hannes Tschofenig To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-suit-architecture@ietf.org" , "suit-chairs@ietf.org" , "suit@ietf.org" , Russ Housley , "mohit.m.sethi@ericsson.com" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc3Vp?= =?utf-8?Q?t-architecture-14:_(with_COMMENT)?= Thread-Index: AQHWs1dckbpCnHchiE+wiGMEkrVk6qnQp8nA Date: Fri, 20 Nov 2020 07:18:57 +0000 Message-ID: References: <160456906093.24545.13517793229178865274@ietfa.amsl.com> In-Reply-To: <160456906093.24545.13517793229178865274@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 930FFA7D1B3FDF4484DDFF59F11604FD.0 x-checkrecipientchecked: true Authentication-Results-Original: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.118.246] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e6e2f044-c6b6-439a-5e7e-08d88d24909d x-ms-traffictypediagnostic: AM4PR0802MB2241:|VE1PR08MB5839: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: LcAzDH6bWoSRakXBfa5YAyp/Sezt9ujMMjl04KigsZvpBio0vS2zYqy0nVogTP2xm3DJrwYGvbHK3ZU776IDV9vtZuWih3vTtAacGv3paI9d5XoVuTSK03XJCLCydPjYgym5Z4OA4JmYx36cuHf8+/Q54IoDuQoXWwcooaJiV9gP2CBNLXr+U57wOq0tsesFi9tFHXENydyn5z++1tYprF9UTkBVqYTmmkMCtPO2TyjQXS5SnozHnYGlsvATaS7CXn2czwqFXtFbrnaRvudMMoOBSY9VyrpQFmKflOIl7HP1LMeTe5OnntGTwk35mWaI0zF/zG3A77ztEE6Yz/P9m8DUzxv2N8M40njJl9egU2tD6pRAZJqGYF6bvkem5+AEVGdJHs6fUsoRf9iAdF2pbQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39850400004)(346002)(136003)(396003)(376002)(71200400001)(52536014)(9686003)(4001150100001)(66556008)(64756008)(66476007)(8936002)(86362001)(186003)(66946007)(26005)(83380400001)(224303003)(33656002)(2906002)(316002)(53546011)(478600001)(6506007)(66446008)(966005)(54906003)(76116006)(110136005)(4326008)(5660300002)(55016002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CEcilbkfqO4lpnrxWsLiPgkGpn7uWEQfKSxO+27U2gHDSdY5KfZhlaBlwsoMjRzc9tUhr5wn55+HvSBLVyFL56bGlZfJY30mK9AntybY1u7C9W80sDaD5+nBqgqRHf2OWAaV02bY9ayuXW0Xo/aW/lAZ9M36/43s9bHnvA174QuF+CT5lV+QcxfepHgcsE0sx2s1XmiKXEDOiRv+uvjAqAYxSSqXsqFjAQ0jH0wd0l3eSmKhCwUZAXefRu/9Vf9KkFa0lGP09uypw4YfO61qfEbuM9b5SzGQ+QOP6grHw+CFxCyP8NZYVIRmvryOxJYZIbpSFS8/J7DktXCwTVOTr6mvD72YHuv4FBFQDv4pdl8uDFMc7E+JWNp+eLf2sUw7ffWM4K0HVE7xkuCPKK8vMQtK6oQIAy6zwA5CQa7YnOlNzRYUeSAY4zhdvXq5fDvsQSc0bcDIozlroqmTteSsZvaU0fgP0KBOx2ZYCZPOthKHfJJSVtWmqcOsuaEVgvlr5HaTFX65e2tyw02rqEUNLa3kP7Gn9+Q5kuDFrALEGxDHz6ZBRM3faJP2do09I/Teyi2RWnbkMvUKvCASp4Wi0HBkYwt5tJJO2lBN/kTXS02CJfJxBpkvnUbTJzKnWH2jpPSTFjdZh4S3WvtN61lHxg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2241 Original-Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: c1131ae1-6c1a-4077-04e3-08d88d248b8c X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oHy+0owwr5oWk3VC4uvFt1yBKbOBwQQKMKWIp9/krU2eNGMdjQmg4o4xsyr3opXyZezfgboc1w//HRi3AnQsiCTJWcGPsADm6oDK4PWqJbg3E5Zm2ynSjARbB0NIxDDyAKoTFEgkrtwGhtQmacv0dXgzmMZQ1g9f8/EO2+snkdMkJNsSmaXC0GJ7hddiPP1zFzKFBQywTn6kQQ9LJmUqS0KSmyN2xd/mjgEngg41PQCGfTu5dDYMbmUBJJTJc2VLQBp+hztjd0M976OPup1ce807CBv3sb4d6TIqlYYoOFGdfy/Ieux+pNOoIWmPJcIjBAPn9zsemB+wukewGxKbKd+51hDG/HfJAthskgMoW2YUW6DUBpc5lr/GO6o88g+1SU5+F3qIAeAJS108HSrz7yiqJ1bawL+TkdSG9kwvBA+MviLUKu7fuf7Gjh/UfjyGLU4Dt5D2woVBKX9dkLUkLIChRmsklhwT3Nwt4v6GaBs= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39850400004)(396003)(346002)(136003)(376002)(46966005)(70206006)(53546011)(7696005)(70586007)(6506007)(224303003)(82310400003)(316002)(55016002)(81166007)(356005)(83380400001)(336012)(52536014)(4326008)(47076004)(86362001)(33656002)(478600001)(8936002)(107886003)(2906002)(82740400003)(450100002)(9686003)(54906003)(26005)(4001150100001)(966005)(5660300002)(186003)(110136005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2020 07:19:05.4548 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e6e2f044-c6b6-439a-5e7e-08d88d24909d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5839 Archived-At: Subject: Re: [Suit] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-suit-architecture-14=3A_=28with_COMMENT=29?= X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 07:19:13 -0000 SGkgRXJpYywNCg0KQnJlbmRhbiBoYXMgYWRkcmVzc2VkIG1vc3Qgb2YgdGhlIHJldmlldyBjb21t ZW50cyBmcm9tIE1vaGl0IGxpc3RlZCBhdA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvcmV2aWV3LWlldGYtc3VpdC1hcmNoaXRlY3R1cmUtMTMtaW90ZGlyLXRlbGVjaGF0LXNldGhp LTIwMjAtMTAtMjAvDQoNCkkgd2FudGVkIHRvIHByb3ZpZGUgYSBmZXcgbWlub3IgcmVtYXJrcyBu ZXZlcnRoZWxlc3MuDQoNCk1vaGl0IHdyb3RlOg0KDQoiDQpIb3cgYWJvdXQgcmVwaHJhc2luZyB0 aGUgdGV4dDogImFyZSBleHBlY3RlZCB0byB3b3JrIGF1dG9tYXRpY2FsbHksIGkuZS4gd2l0aG91 dCB1c2VyIGludm9sdmVtZW50LiBBdXRvbWF0aWMgdXBkYXRlcyB0aGF0IGRvIG5vdCByZXF1aXJl IGh1bWFuIGludGVydmVudGlvbiBhcmUga2V5IHRvIGEgc2NhbGFibGUgc29sdXRpb24gZm9yIGZp eGluZyBzb2Z0d2FyZSB2dWxuZXJhYmlsaXRpZXMuIiB0byAiYXJlIG8gYSBsYXJnZSBleHRlbnQg ZXhwZWN0ZWQgdG8gd29yayBhdXRvbWF0aWNhbGx5LCBpLmUuIHdpdGggbWluaW1hbCBodW1hbiBp bnRlcmFjdGlvbi4gQXV0b21hdGljIHVwZGF0ZXMgdGhhdCByZXF1aXJlIG1pbmltYWwgb3Igbm8g aW50ZXJhY3Rpb24gYXJlIGtleSB0byBhIC4uLi4iLiBUaGUgcmVhc29uIGZvciByZXF1ZXN0aW5n IHRoaXMgY2hhbmdlIGlzIHNpbXBsZTogaW4gbWFueSBzY2VuYXJpb3MgeW91IHdvdWxkIHdhbnQg dXNlciBhcHByb3ZhbCBiZWZvcmUgdGhlIGFjdHVhbCB1cGRhdGUuIEZvciBleGFtcGxlLCB1cGRh dGluZyBsaWdodHMgYXQgbmlnaHQgZHVyaW5nIGRpbm5lciBpcyBwZXJoYXBzIG5vdCBpZGVhbC4g VGhlIGRyYWZ0IGRvZXMgZGlzY3VzcyB0aGUgaW1wb3J0YW5jZSBvZiBkZXZpY2Ugb3BlcmF0b3Ig YXBwcm92YWwgaW4gc29tZSBjaXJjdW1zdGFuY2VzIHNvIHVwZGF0aW5nIHRoZSB0ZXh0IHdvdWxk IG1ha2Ugc2Vuc2UuDQoiDQoNCkl0IGlzIHRydWUgdGhhdCBzb21lb25lIGhhcyB0byBpbml0aWF0 ZSB0aGUgdXBkYXRlIGFuZCBkaWZmZXJlbnQgZGVjaXNpb25zIHdpbGwgaW5mbHVlbmNlIG9uIHdo ZW4gdGhpcyBoYXBwZW5zLiBJbiBtYW55IHN5c3RlbXMgdGhlIHVzZXIgb2YgdGhlIGRldmljZSBp cyBhc2tlZCBieSB0aGUgZGV2aWNlIHRvIGRvd25sb2FkIHRoZSB1cGRhdGUgYW5kIHRvIGFwcGx5 IGl0LiBXaXRoIGRldmljZXMgdGhhdCBhcmUgaGF2ZSB1c2VyIGludGVyZmFjZXMgdGhpcyBpcyBv ZnRlbiB0aGUgY2FzZS4gQm9iIEJyaXNjb2Ugc2hhcmVkIGhpcyBleHBlcmllbmNlIHdpdGggQklP UyB1cGRhdGVzIG9uIGRlc2t0b3Agc3lzdGVtcyB0aGF0IHdhc24ndCBzbW9vdGggZGVzcGl0ZSBo YXZpbmcgYSBncmVhdCB1c2VyIGludGVyZmFjZS4gVGhlIElvVCBlY29zeXN0ZW0gaXMgcXVpdGUg YnJvYWQgYW5kIHRoZXJlIHdpbGwgYmUgY2FzZXMgdGhhdCBjYW4gd29yayBmaW5lIHdpdGggbm9u LWF1dG9tYXRlZCBzb2Z0d2FyZSB1cGRhdGVzLiBXaGVuIHlvdSB3YW50IHRvIHVwZGF0ZSBhIGxh cmdlIG51bWJlciBvZiB1bmF0dGVuZGVkIGRldmljZXMgdGhlbiB0aGVyZSBpcywgaG93ZXZlciwg YSBjaGFsbGVuZ2UuIFdlIGFyZSBhZGRyZXNzaW5nIHRoZSBsYXR0ZXIgcmF0aGVyIHRoYW4gdGhl IGZvcm1lci4NCg0KSSBjaGFuZ2VkIHRoZSB0ZXh0IHRvDQoiDQpGaXJtd2FyZSB1cGRhdGVzICBm b3IgSW9UIGRldmljZXMgYXJlICoqbGFyZ2VseSoqIGV4cGVjdGVkIHRvIHdvcmsgYXV0b21hdGlj YWxseSwgaS5lLiB3aXRob3V0IHVzZXIgaW52b2x2ZW1lbnQuDQoiDQpJZiB0aGVyZSBpcyBhIGJl dHRlciB3YXkgdG8gZ2V0IHRoaXMgc3RvcnkgYWNyb3NzLCBwbGVhc2UgbGV0IG1lIGtub3cuDQoN Cg0KTW9oaXQgYXNrZWQNCg0KIg0KSSB3b25kZXIgaWYgeW91IHdhbnQgdG8gc3RhdGUgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBzb2Z0d2FyZSBhbmQgZmlybXdhcmUgdXBkYXRlLiBBcmUgdGhleSB0 aGUgc2FtZSB0aGluZyBmb3IgdGhpcyBkb2N1bWVudD8gVGhlIHRleHQgaW4gdGhlIGRyYWZ0IGF0 IHNvbWUgcG9pbnQgc2F5cyAiTW9yZW92ZXIsIHRoaXMgYXJjaGl0ZWN0dXJlIGlzIG5vdCBsaW1p dGVkIHRvIG1hbmFnaW5nIHNvZnR3YXJlIHVwZGF0ZXMiLiBCdXQgbW9zdCBvZiB0aGUgb3RoZXIg dGV4dCB0YWxrcyBhYm91dCAiZmlybXdhcmUgdXBkYXRlcyIuDQoiDQoNClNpbmNlIHRoaXMgd2Fz IGEgcXVlc3Rpb24gdGhhdCBzdXJmYWNlZCBpbiB0aGUgZ3JvdXAgYmVmb3JlIHdlIGhhdmUgKGlu IHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkcmFmdCkgZXhwYW5kZWQgdGhlIGRlc2NyaXB0aW9u IGFib3V0IHdoYXQgYSBmaXJtd2FyZSBpbWFnZSBpcy4gSGVyZSBpcyB0aGUgdGV4dDoNCg0KIg0K ICAgLSAgRmlybXdhcmUgSW1hZ2U6IFRoZSBmaXJtd2FyZSBpbWFnZSwgb3IgaW1hZ2UsIGlzIGEg YmluYXJ5IHRoYXQgbWF5DQogICAgICBjb250YWluIHRoZSBjb21wbGV0ZSBzb2Z0d2FyZSBvZiBh IGRldmljZSBvciBhIHN1YnNldCBvZiBpdC4gIFRoZQ0KICAgICAgZmlybXdhcmUgaW1hZ2UgbWF5 IGNvbnNpc3Qgb2YgbXVsdGlwbGUgaW1hZ2VzLCBpZiB0aGUgZGV2aWNlDQogICAgICBjb250YWlu cyBtb3JlIHRoYW4gb25lIG1pY3JvY29udHJvbGxlci4gIE9mdGVuIGl0IGlzIGFsc28gYQ0KICAg ICAgY29tcHJlc3NlZCBhcmNoaXZlIHRoYXQgY29udGFpbnMgY29kZSwgY29uZmlndXJhdGlvbiBk YXRhLCBhbmQNCiAgICAgIGV2ZW4gdGhlIGVudGlyZSBmaWxlIHN5c3RlbS4gIFRoZSBpbWFnZSBt YXkgY29uc2lzdCBvZiBhDQogICAgICBkaWZmZXJlbnRpYWwgdXBkYXRlIGZvciBwZXJmb3JtYW5j ZSByZWFzb25zLg0KDQogICAgICBUaGUgdGVybXMsIGZpcm13YXJlIGltYWdlLCBmaXJtd2FyZSwg YW5kIGltYWdlLCBhcmUgdXNlZCBpbiB0aGlzDQogICAgICBkb2N1bWVudCBhbmQgYXJlIGludGVy Y2hhbmdlYWJsZS4gIFdlIHVzZSB0aGUgdGVybSBhcHBsaWNhdGlvbg0KICAgICAgZmlybXdhcmUg aW1hZ2UgdG8gZGlmZmVyZW50aWF0ZSBpdCBmcm9tIGEgZmlybXdhcmUgaW1hZ2UgdGhhdA0KICAg ICAgY29udGFpbnMgdGhlIGJvb3Rsb2FkZXIuICBBbiBhcHBsaWNhdGlvbiBmaXJtd2FyZSBpbWFn ZSwgYXMgdGhlDQogICAgICBuYW1lIGluZGljYXRlcywgY29udGFpbnMgdGhlIGFwcGxpY2F0aW9u IHByb2dyYW0gb2Z0ZW4gaW5jbHVkaW5nDQogICAgICBhbGwgdGhlIG5lY2Vzc2FyeSBjb2RlIHRv IHJ1biBpdCAoc3VjaCBhcyBwcm90b2NvbCBzdGFja3MsIGFuZA0KICAgICAgZW1iZWRkZWQgb3Bl cmF0aW5nIHN5c3RlbSkuDQoiDQoNClNvZnR3YXJlIGlzIGEgdmVyeSBnZW5lcmljIHRlcm0uIENv bXBhcmluZyBmaXJtd2FyZSB3aXRoIHNvZnR3YXJlIHdvdWxkIHJlcXVpcmUgdXMgdG8gZ28gaW50 byB0aGUgZGV0YWlscyBvZiBhIHNwZWNpZmljIHBpZWNlIG9mIHNvZnR3YXJlLiBTb2Z0d2FyZSB0 aGF0IGlzIGRpc3RyaWJ1dGVkIGF0IGhpZ2hlciBsYXllcnMgaGFzIHR5cGljYWxseSB0aGVpciBv d24gc29mdHdhcmUgZGlzdHJpYnV0aW9uIHN5c3RlbSBhbmQgdW5pcXVlIHNlY3VyaXR5IGNoYWxs ZW5nZXMgYmFzZWQgb24gdGhlIGVudmlyb25tZW50IGl0IGlzIHJ1biBpbi4NCg0KVGhlIHJlZmVy ZW5jZSB0byAiTW9yZW92ZXIsIHRoaXMgYXJjaGl0ZWN0dXJlIGlzIG5vdCBsaW1pdGVkIHRvIG1h bmFnaW5nIHNvZnR3YXJlIHVwZGF0ZXMiIHdhcyBpbnRyb2R1Y2VkIGJlY2F1c2Ugd2UgdXNlIFNV SVQgYWxzbyBmb3IgVEVFUCB3aGVyZSB0cnVzdGVkIGFwcGxpY2F0aW9ucyBydW4gaW4gYSBzcGVj aWFsIG1vZGUgb2YgdGhlIHByb2Nlc3Nvci4NCg0KTW9oaXQgYWxzbyB3cml0ZXM6DQoNCiINCkkg dGhpbmsgbW9zdCByZWFkZXJzIHdpbGwgYmUgbW9yZSBmYW1pbGlhciB3aXRoIHRoZSB0ZXJtIE9y aWdpbmFsIEVxdWlwbWVudCBNYW51ZmFjdHVyZSAoT0VNKSByYXRoZXIgdGhhbiBPcmlnaW5hbCBE ZXNpZ24gTWFudWZhY3R1cmVyIChPRE0pLiBJIHVuZGVyc3RhbmQgdGhhdCBBUk0gaGFzIGEgc2xp Z2h0bHkgY29tcGxpY2F0ZWQgZWNvc3lzdGVtIGFuZCBidXNpbmVzcyBtb2RlbC4gU28gcGVyaGFw cyB0aGUgdGV4dCBjb3VsZCBzYXkgImluIHNvbWUgY2FzZXMsIHRoZSBPRU0gb3IgdGhlIE9ETSBh Y3QgYXMgYSBUUEEgYW5kIG1heSBkZWNpZGUgdG8gcmVtYWluIGluIGZ1bGwgY29udHJvbC4uLi4i DQoiDQoNClRoaXMgaXMgbm90IHRlcm1pbm9sb2d5IHdlIGNhbWUgdXAgd2l0aC4gT24gdGhlIHN1 cmZhY2UsIHRoZSBtYW51ZmFjdHVyaW5nIHByb2Nlc3MgZm9yIGVtYmVkZGVkIGRldmljZXMgbG9v a3MgcXVpdGUgc2ltcGxlIGJ1dCBpbiBwcmFjdGljZSB0aGlzIGlzIG5vdCB0aGUgY2FzZS4gVGhp cyBpcyB3aHkgdGhlcmUgaXMgbm93IHNvIG11Y2ggaW50ZXJlc3QgaW4gc3VwcGx5IGNoYWluIHNl Y3VyaXR5IHRvZGF5IGJlY2F1c2UgdGhlIGZpbmFsIHByb2R1Y3QgaXMgY3JlYXRlZCB3aXRoIHNv IG1hbnkgZGlmZmVyZW50IGNvbXBvbmVudHMgdGhhdCBhbGwgY29tZSBmcm9tIGRpZmZlcmVudCBw YXJ0aWVzLiBUaGlzIHByb2Nlc3MgaXMgYSBieS1wcm9kdWN0IG9mIGhvdyB0aGUgZWNvbm9teSB3 b3JrcyB3aGVyZSBzcGVjaWFsaXphdGlvbiBpcyBjb21tb24uDQoNCkFub3RoZXIgaXRlbSBpczoN Cg0KIg0KVGhlIGRyYWZ0IHVzZXMgVEFzIGZvciB0cnVzdGVkIGFwcGxpY2F0aW9ucyAoVEFzKS4g QnV0IFJGQyA2MDI0IHJlZmVyZW5jZWQgYnkgdGhpcyBkb2N1bWVudCB1c2VzIFRBcyBmb3IgVHJ1 c3QgYW5jaG9ycy4gQ2FuIHdlIGF2b2lkIHVzaW5nIFRBIGFiYnJldmlhdGlvbnMgZm9yIHRydXN0 ZWQgYXBwbGljYXRpb25zIGZvciA/DQoiDQoNCjItIGFuZCAzLWxldHRlciBhY3Jvbnltb3VzIHdp bGwgbGVhZCB0byBjb2xsaXNpb25zLCBhcyB3ZSBoYXZlIHRoZSBjYXNlIGhlcmUuIFNpbmNlIHdl IGNhbm5vdCBjaGFuZ2UgdGhlIGFjcm9ueW1vdXMgSSBob3BlIHdlIG1hZGUgY2xlYXIgaW4gdGhl IGNvbnRleHQgd2hpY2ggb25lIHdlIHRhbGsgYWJvdXQuDQoNCkNpYW8NCkhhbm5lcw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tl ciA8bm9yZXBseUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciA1LCAyMDIwIDEw OjM4IEFNDQpUbzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1zdWl0 LWFyY2hpdGVjdHVyZUBpZXRmLm9yZzsgc3VpdC1jaGFpcnNAaWV0Zi5vcmc7IHN1aXRAaWV0Zi5v cmc7IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBob3VzbGV5QHZpZ2lsc2Vj LmNvbTsgbW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20NClN1YmplY3Q6IMOJcmljIFZ5bmNrZSdz IE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXN1aXQtYXJjaGl0ZWN0dXJlLTE0OiAod2l0aCBD T01NRU5UKQ0KDQrDiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLXN1aXQtYXJjaGl0ZWN0dXJlLTE0OiBObyBPYmplY3Rp b24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zdWl0LWFyY2hpdGVj dHVyZS8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRo YW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1bWVudC4NCg0KUGxlYXNlIGFk ZCByZWZlcmVuY2UgdG8gTHdNMk0gaW4gU2VjdGlvbiAxLg0KDQpQbGVhc2UgYWxzbyBhZGRyZXNz IGFsbCBjb21tZW50cyByYWlzZWQgYnkgTW9oaXQgU2V0aGkgZHVyaW5nIHRoZSBJb1QgZGlyZWN0 b3JhdGUgcmV2aWV3IChJIHNhdyB0aGF0IEJyZW5kYW4gaGFzIGFscmVhZHkgcmVwbGllZCk6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZXZpZXctaWV0Zi1zdWl0LWFyY2hpdGVj dHVyZS0xMy1pb3RkaXItdGVsZWNoYXQtc2V0aGktMjAyMC0xMC0yMC8NCg0KSSBob3BlIHRoYXQg dGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwNCg0KUmVnYXJkcywNCg0KLcOpcmlj DQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Fri Nov 20 09:05:58 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30183A0F0B; Fri, 20 Nov 2020 09:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=0L1/K4jp; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=0L1/K4jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4AuqDJNjE-8; Fri, 20 Nov 2020 09:04:53 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150058.outbound.protection.outlook.com [40.107.15.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830C83A0EC3; Fri, 20 Nov 2020 09:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bT/LGBvGgEbLze9IVSrKDxfD2zitnpHAgb6KZG8N7lA=; b=0L1/K4jpK3hXYXiz30dkbRVUFaKAvXBW6D9Ldz/SFJ8IEdjhk+V3EzxPB+Lusrq8niGfssVBOY4+FA9hQaBBo8jqEZovr+X2gw9jPdcQQzNbJstE7mqY438FPDsFxZ2pD4R06H3FYSrPoNTtKWJ7iZGwkWZnlhhlwkv7s2OGm9s= Received: from DB3PR06CA0010.eurprd06.prod.outlook.com (2603:10a6:8:1::23) by DB8PR08MB5241.eurprd08.prod.outlook.com (2603:10a6:10:e2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Fri, 20 Nov 2020 17:04:48 +0000 Received: from DB5EUR03FT036.eop-EUR03.prod.protection.outlook.com (2603:10a6:8:1:cafe::15) by DB3PR06CA0010.outlook.office365.com (2603:10a6:8:1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 17:04:48 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT036.mail.protection.outlook.com (10.152.20.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Fri, 20 Nov 2020 17:04:48 +0000 Received: ("Tessian outbound fcd5bc555ddc:v71"); Fri, 20 Nov 2020 17:04:48 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 0b919fcffe2e1d9a X-CR-MTA-TID: 64aa7808 Received: from fa396eed2dbf.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B2C01B6C-C17A-430D-AC0D-885E4DDA6DFF.1; Fri, 20 Nov 2020 17:04:42 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fa396eed2dbf.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 20 Nov 2020 17:04:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jVomx/4AJDdWSuX5MomkGLOc4eNQwuWnPSqAUwhewbia8MYmkeBWCaciUJWLFTUcNcVDiOURtKEoa2ByXrQr4YmqhS9JilVznVrS3MK96vet/qtx2Ry5dHEPkQ7w+enGH0F1y4cKRe9fZZ6iYMBZKJv2BaimL1DFsDX+un+634uqcifwOavoWkFZ1q6AcGzQAuZZFJoz8/SlLn6/0Mgv6epRen93BWXtGnKMmYDbuwl/UXvX2gqSqkpeJ5nmylLQh/jnxZhVwPcJ468321FIk1iOYJMFXlGBNMQ3m6Q/dYHpVPY2kuJE/DMWOVikj0mk/23MADzne2W0Efj7xzXBmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bT/LGBvGgEbLze9IVSrKDxfD2zitnpHAgb6KZG8N7lA=; b=HC8cEIli5xctsyZoMeW7pDkW7Pz1Dyzh5jUf2I+YpP+En4at3Llwj+jJQPHX34biAy38WVNSSSCwwpazUYtmOGCyDzAO/eezmBHgm3AGnXa809A/Pt8Gruj+4BGkYp05SLqAo0dkdMdg3h+cg8JKtjWEQDUnFbjdVqJdO74ciIhY3jpX/Abzq/CLmw5UFQLoqCiMoqaGQO9HsmO6X/f9PJFTziYZhKq8U10qlD0gIBnia3sVz+x3LJEkrXVeOHVo8xOwPDyIuiUBywOXcVvCw74cLMwKTwELsXCPPCOzfw4yDJ09CUoErajnsFUMBh/BdAIwpOIqLH9FhFHnsTYsQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bT/LGBvGgEbLze9IVSrKDxfD2zitnpHAgb6KZG8N7lA=; b=0L1/K4jpK3hXYXiz30dkbRVUFaKAvXBW6D9Ldz/SFJ8IEdjhk+V3EzxPB+Lusrq8niGfssVBOY4+FA9hQaBBo8jqEZovr+X2gw9jPdcQQzNbJstE7mqY438FPDsFxZ2pD4R06H3FYSrPoNTtKWJ7iZGwkWZnlhhlwkv7s2OGm9s= Received: from AM9PR08MB6146.eurprd08.prod.outlook.com (2603:10a6:20b:2db::17) by AM9PR08MB6195.eurprd08.prod.outlook.com (2603:10a6:20b:284::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Fri, 20 Nov 2020 17:04:41 +0000 Received: from AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5]) by AM9PR08MB6146.eurprd08.prod.outlook.com ([fe80::c848:df2:1b39:78d5%4]) with mapi id 15.20.3589.021; Fri, 20 Nov 2020 17:04:41 +0000 From: Brendan Moran To: Toerless Eckert CC: Benjamin Kaduk , Russ Housley , "suit-chairs@ietf.org" , suit , The IESG , "draft-ietf-suit-architecture@ietf.org" Thread-Topic: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) Thread-Index: AQHWs1eEcjyU/Z29aUm24cS5YMgJianOhzuAgADbPQCAASOtgIAA0aMA Date: Fri, 20 Nov 2020 17:04:41 +0000 Message-ID: <8AF680F5-D4C4-4EB8-976C-9CBBAC9F6161@arm.com> References: <160456913386.24093.10722400425795162498@ietfa.amsl.com> <20201119111024.GD39170@kduck.mit.edu> <20201120043421.GT39343@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20201120043421.GT39343@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) Authentication-Results-Original: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.7.184.196] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 635b9f58-d8cc-4b01-4cdd-08d88d766363 x-ms-traffictypediagnostic: AM9PR08MB6195:|DB8PR08MB5241: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 0TFNocgML0yy6Oa7/vwBk/6BeVvxW94k/ZixnGb8P0k/PiatBqt5pZPvqsEk3Sac+i7Gezw2iexLWqGtRGkw00cVAiryFG3GrqmPNCOd74kuHFl3+v3m8NLEKCpE5BOH6H9Ts+ihe1Ag4zSUXmZKWhRsvmPLHNx/KOiNtepggehDniU8aSCFL+UQX7cHLeFjpdVsRvaOheCiEuRl4NjrqB2mnf3xsdJZDyk8HHvtOQd3/jKDxSBQR+tsjIVrdfq74QZjiZ+3/pQuygwkvnj1TQWXX1uF+yXvGjxdC4pdL2/w6nMV+/vL1fqj9g3Q3UR4F0p3PFvSwGOKMDB7XSQsNpc2s9Qw/bHc0h0c6VxK+gosR8VkpCQQfDE9jYHsIElv602gFfyQxRVrpFBvpKuCMA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR08MB6146.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(366004)(136003)(396003)(346002)(45080400002)(66446008)(64756008)(76116006)(66556008)(478600001)(66946007)(54906003)(4326008)(66476007)(2616005)(83380400001)(316002)(86362001)(186003)(966005)(6486002)(8936002)(6916009)(8676002)(71200400001)(5660300002)(2906002)(91956017)(33656002)(26005)(6512007)(36756003)(53546011)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: O7sAwBas7dngBMmdPtqqmciQnAIyUKdCuX3yChYUyT7AE3ZzYEu0ZiPf7RzORKj8i/Ih0T8yFrfmb9rEtpBQ26LsqBfsB+aL/Ljkwba7VjSXMg6vgDOEYpoCGfon2jU3lcEJwC3d9h6iJThqTSJQeyPw7NXmMWSBSXhAE/XEz/wWcZBx0zO9ksBIlmUvhn7ECCOEyt7i9ELphNTdSgRm1g0ksFHHbGHxiNvpTZ5+u69+5HhO+0KrHRZaR4PsHAfUKFC10RdShRMuGx8zrz9u0uceO59u9vUcgfAYL83nw+2GTB9K8X9hE529BR3OcZlYa+ozkWQet0TBWN8bBnynjeaDrEXVeorDvzy1R+uFlH+QUy7bG9n7ofjnOwSlhJ9mlLVET/WJuy8rrK0QCwvB4MtPzdGhbfA9p0/U5zzfe3M1+NUfe4mrmG8vfclfobsNn6hHvqXb+12uFAiEKdKj5FW7xy4bGiseOiu/00n/vqLOtzYwpRHScmmHd2TIwhywBsEi9GwKDouPev2Rck+BBPIrd9dYdjWDv+CT+U9Z04hmTqzWB0TCglHqBCAEi3VJEd46I00IrnwAtnCdQU1ZILL7mukB5nqwCuicg7yv2Ix+9RKObs5YyQ4jpCs5mNabkPxdXupRrpTVQ8Qo7SdNCj/pQz+5vzKKXRarifz2ckFcU3Z/bntu57HTbeckCjxPyfL+HW6t2mPUbLxPnSh2INSqTVeEUy6d8MCiELODuc4B4zLct5gad5xfb0fOWwxsQ7o8K+a5EEGWBSySDJ5ven6hwdnqpOEhDl8iq88TaOWnSLNRZCgBzCqQcS4o2M/m2CVnamTRMYAj+5r2HPqvwjxOScA1VQaItJX4DXoNQGOeM/PwXqveuCPWG5qSEDXjhFvJnrlHTJ32Jg3aPbTTXQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <84207C7A26AF9D46B192BBD7331CAC10@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6195 Original-Authentication-Results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT036.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 2f62aa20-ad0c-4bce-e4e4-08d88d765f1f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PKlMd6JlyGMbYl3uges71KZfr2DMvEPbKr/Sj1pVHWfcvxmyDzveTHcd6CgSrApbsnunABNqA+cWaAQBx108dQ95YZoj4P1OwqHDtO8HD/db/HXfSNdDxfZgD+U/j/T4EoVojazBaaXVqT/qSjrFU3eL1/9o/uhsansOFLHGGnEvhPs8TRi1LeHlpvv7jGF5Se5aXIHQwXkRBxFnHzkvaFMIVPzn83tshdyQEP1HPpYJIwjxVa6nHL31UT0eMs3IngDaoVvuBJrZl1Kd4mEqK8lxTyDIWMJmqWequ5BHphkQ1Tj32t15HBDvSZrhFEmiyHgiCs4hJtGI/UxPb6kMjm+gNKWZwY2emwqNRuIgA0j0uiHdgidycV9BBnN20Psy+F5lTy5jtO+IazJ3lxfhvoTV847IBjr89cKAydcHZBK3AnQPUJSzxcjWcFH1HNUYSGpOzed3IGpw4ypZZqYfJWE6u/ZQAbQdk5ssu59njVQ= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(346002)(39860400002)(46966005)(8676002)(83380400001)(186003)(356005)(6486002)(2616005)(53546011)(26005)(45080400002)(5660300002)(6862004)(54906003)(966005)(70586007)(316002)(70206006)(450100002)(82310400003)(2906002)(478600001)(6506007)(4326008)(6512007)(33656002)(82740400003)(336012)(81166007)(36756003)(47076004)(86362001)(8936002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2020 17:04:48.5874 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 635b9f58-d8cc-4b01-4cdd-08d88d766363 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT036.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5241 Archived-At: Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 17:04:58 -0000 Hi Toerless, In fact, this is not original research by me. You can find an article that = details this analysis here: https://www.linkedin.com/pulse/breaking-rsa-enc= ryption-update-state-of-the-art-andreas-baumhof I checked the references and I think that the conclusions are sound. Brendan > On 20 Nov 2020, at 04:34, Toerless Eckert wrote: > > Benjamin, *: > > I do not think that the simple extension of the current text explanation > to include "and the trend in quantum annealing capacity" would help: > > From reading Brendans text below and doing a quick search through > [quantum-factorization], it looks to me as if the conclusion > currently written into the draft "... approximately 2030 ..." is an origi= nal > research conclusion by Brendan et.al. and can not be directly found in > [quantum-factorization]. The actual reference for the conclusion is > the text below from Brendan, and if the 2030 prediction is to be kept in = the > text then readers should be made aware of this original research. > > I would obviously like to see the three paragraphs from Brendan put > somewhere into the draft (appendix or the like), but if the authors worry= about length, then > they could simply put a reference to Brendans email into the draft > (aka: see [https://mailarchive.ietf.org/arch/msg/suit/Ao2OlGo0yhjLncVftTL= AJ2jjw2E/]) > > Cheers > Toerless > > On Thu, Nov 19, 2020 at 03:10:24AM -0800, Benjamin Kaduk wrote: >> Hi Brendan, >> >> Thanks for the extra reference and discussion about the timescale estima= tes >> for quantum computers and integer factorization. (And for accepting mos= t >> of my other comments.) I see now how the factorization-by-annealing >> reference was intended to be used, and had not been paying close enough >> attention to know the 5640-qbit and doubling-every-two-years numbers for >> D-Wave. >> >> If I was going to suggest a change to the text, it would be quite small, >> perhaps something like "based on current research [quantum-factorization= ] >> and the trend in quantum annealing capacity". >> >> Thanks again, >> >> Ben >> >> On Wed, Nov 18, 2020 at 10:05:44PM +0000, Brendan Moran wrote: >>> We will take on board the majority of these comments. >>> >>> WRT the PQC time horizon, quantum annealing attacks on RSA are dependen= t commercial quantum annealers. >>> >>> The paper in nature shows the factorisation of 376,289 in 94 qubits. In= fact, other researchers have factored 1,005,973 with only 89 qubits [1]. W= ith this second algorithm, characterised as O(log^2(N)), RSA-768 would requ= ire 147,454 qubits. D-Wave has shipped quantum computers with 5640 qubits a= lready. They have a historical average of doubling the number of qubits eve= ry two years. Based on this trajectory, they should be shipping a quantum c= omputer that can break RSA-768 in approximately 2030 (log_2(147454/5640)) = =3D 4.7 =3D> 9.4 years. RSA-2048, then, would be broken between 2 and 4 yea= rs later, and RSA-4096 a mere 2 years after that. >>> >>> This is a naive analysis. However, it is intended to show that a scalab= le general purpose quantum computer is not the only threat to current crypt= ographic techniques, that the time horizon is not long, and that urgent act= ion is required to ensure that devices with long lifetimes account for EITH= ER cryptographic agility or quantum safety, preferably the latter, since qu= antum safe algorithms require much more data than classical asymmetric cryp= to and, therefore, require extra considerations, particularly when used in = constrained IoT. >>> >>> Obviously, the hole in this analysis is that RSA is not common in IoT. = I have not yet found equivalent research that shows how a quantum annealer = could attack ECDSA or EDDSA. I assume that there are research teams working= on this. We should prepare ourselves for the potential of that particular = revelation. >>> >>> We have not gone into this detail in the architecture because it seems = both orthogonal to the general discussion in the architecture, extremely ti= me-sensitive, and extremely algorithm-sensitive. It will be an irrelevant p= rediction and analysis within a handful of years. >>> >>> Best Regards, >>> Brendan >>> >>> [1] https://link.springer.com/article/10.1007/s11433-018-9307-1 >>> >>> >>>> On 5 Nov 2020, at 09:38, Benjamin Kaduk via Datatracker wrote: >>>> >>>> Benjamin Kaduk has entered the following ballot position for >>>> draft-ietf-suit-architecture-14: No Objection >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut thi= s >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Does the XIP case mean that repeated firmware updates would have >>>> potential to cause undue wear on the fixed flash cells that hold the >>>> firmware image? If so, this might be noted in the security >>>> considerations. >>>> >>>> I am not sure that I have fully digested Bob Briscoe's detailed review >>>> comments, but it seems like we may want to continue to reflect on whic= h >>>> portions of the architecture will be optional to implement, and how we >>>> might indicate that in the document. >>>> >>>> I also made a pull request for some editorial nits at >>>> https://github.com/suit-wg/architecture/pull/15 . >>>> >>>> Section 1 >>>> >>>> otherwise difficult. Firmware updates >>>> for IoT devices are expected to work automatically, i.e. without user >>>> involvement. Conversely, IoT devices are expected to account for >>>> user preferences and consent when scheduling updates. Automatic >>>> >>>> I can't quite tell if the "Conversely" case is intending to refer to I= oT >>>> or non-IoT devices. >>>> >>>> The firmware update process has to ensure that >>>> >>>> - The firmware image is authenticated and integrity protected. >>>> [...] >>>> >>>> - The firmware image can be confidentiality protected so that >>>> attempts by an adversary to recover the plaintext binary can be >>>> [...] >>>> >>>> Perhaps it's just because Bob Briscoe's comments are fresh in my mind, >>>> but there seems to be something of a mismatch across these texts -- we >>>> "have to ensure" that the firmware *is* authenticated and integrity >>>> protected, but only that the image *can be* confidentiality protected. >>>> Is it really the case that we can ensure that an update process *can b= e* >>>> confidentiality protected, or is the confidentiality requirement more = of >>>> a requirement on the architecture than on actual deployment? >>>> >>>> While the IETF standardization work has been focused on the manifest >>>> format, a fully interoperable solution needs more than a standardized >>>> manifest. For example, protocols for transferring firmware images >>>> and manifests to the device need to be available as well as the >>>> status tracker functionality. Devices also require a mechanism to >>>> discover the status tracker(s) and/or firmware servers, for example >>>> using pre-configured hostnames or [RFC6763] DNS-SD. These building >>>> blocks have been developed by various organizations under the >>>> umbrella of an IoT device management solution. The LwM2M protocol is >>>> one IoT device management protocol. >>>> >>>> We might put some forward references to things we do cover (like statu= s >>>> tracker(s)), and a reference for LwM2M as well. >>>> >>>> Section 3 >>>> >>>> Hence, the following components are necessary on a device for a >>>> firmware update solution: >>>> [...] >>>> - a status tracker. >>>> >>>> Earlier we said that having the status tracker on the device was fairl= y >>>> uncommon. >>>> >>>> Section 7 >>>> >>>> time horizon for quantum-accelerated key extraction. The worst-case >>>> estimate, at time of writing, for the time horizon to key extraction >>>> with quantum acceleration is approximately 2030, based on current >>>> research [quantum-factorization]. >>>> >>>> I'm not sure that I see how the reference suports the "approximately >>>> 2030" statement. >>>> >>>> >>>> >>> >>> IMPORTANT NOTICE: The contents of this email and any attachments are co= nfidential and may also be privileged. If you are not the intended recipien= t, please notify the sender immediately and do not disclose the contents to= any other person, use it for any purpose, or store or copy the information= in any medium. Thank you. >> >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit > > -- > --- > tte@cs.fau.de IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Sat Nov 21 00:42:42 2020 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8983A0CD6; Sat, 21 Nov 2020 00:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb-MZEtiVheV; Sat, 21 Nov 2020 00:42:32 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053983A0CD5; Sat, 21 Nov 2020 00:42:31 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AL8gLLt009250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Nov 2020 03:42:26 -0500 Date: Sat, 21 Nov 2020 00:42:21 -0800 From: Benjamin Kaduk To: Hannes Tschofenig Cc: Brendan Moran , Russ Housley , "suit-chairs@ietf.org" , suit , The IESG , "draft-ietf-suit-architecture@ietf.org" Message-ID: <20201121084221.GW39170@kduck.mit.edu> References: <160456913386.24093.10722400425795162498@ietfa.amsl.com> <20201119111024.GD39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 08:42:37 -0000 Hi Hannes, The PRs look good; thanks. Following up inline on the bit that was unclear... On Fri, Nov 20, 2020 at 06:27:32AM +0000, Hannes Tschofenig wrote: > Hi Ben > > Thanks for your review and for your PR with the proposed changes. > > I have created PRs to address some of your remarks: > https://github.com/suit-wg/architecture/pull/16 > https://github.com/suit-wg/architecture/pull/17 > > I have addressed the remark below in PR #16: > > " > Section 1 > > otherwise difficult. Firmware updates > for IoT devices are expected to work automatically, i.e. without user > involvement. Conversely, IoT devices are expected to account for > user preferences and consent when scheduling updates. Automatic > > I can't quite tell if the "Conversely" case is intending to refer to IoT > or non-IoT devices. > " > > The remark below is addressed in PR#16: > > " > The firmware update process has to ensure that > > - The firmware image is authenticated and integrity protected. > [...] > > - The firmware image can be confidentiality protected so that > attempts by an adversary to recover the plaintext binary can be > [...] > > Perhaps it's just because Bob Briscoe's comments are fresh in my mind, > but there seems to be something of a mismatch across these texts -- we > "have to ensure" that the firmware *is* authenticated and integrity > protected, but only that the image *can be* confidentiality protected. > Is it really the case that we can ensure that an update process *can be* > confidentiality protected, or is the confidentiality requirement more of > a requirement on the architecture than on actual deployment? > " > > The comment below is addressed in PR#17: > > " > While the IETF standardization work has been focused on the manifest > format, a fully interoperable solution needs more than a standardized > manifest. For example, protocols for transferring firmware images > and manifests to the device need to be available as well as the > status tracker functionality. Devices also require a mechanism to > discover the status tracker(s) and/or firmware servers, for example > using pre-configured hostnames or [RFC6763] DNS-SD. These building > blocks have been developed by various organizations under the > umbrella of an IoT device management solution. The LwM2M protocol is > one IoT device management protocol. > > We might put some forward references to things we do cover (like status > tracker(s)), and a reference for LwM2M as well. > " > > I did not make changes regarding this comment because I couldn't find text that claimed that the status tracker on the device is uncommon. > > " > Section 3 > > Hence, the following components are necessary on a device for a > firmware update solution: > [...] > - a status tracker. > > Earlier we said that having the status tracker on the device was fairly > uncommon. > " I suspect I was thinking about this text in Section 2.3: - Firmware Server: The firmware server stores firmware images and manifests and distributes them to IoT devices. Some deployments may require a store-and-forward concept, which requires storing the firmware images/manifests on more than one entity before they reach the device. There is typically some interaction between the firmware server and the status tracker and these two entities are often physically separated on different devices for scalability reasons. Specifically "often physically separated on different devices". > The issue about post-quantum crypto is being discussed separately. > > Regarding the comment below I still have to think about how to best address it. > Flash memory wears out but there are different flash memories and there are flash controllers trying to prevent uneven wear-out. > I have to think about what the draft should discuss regarding the implications of execute in place (XIP) with respect to the wear of flash memory. It's quite possible that "what the draft should discuss" ends up being "nothing", especially if the same flash chips are used for other operations that incure significantly more frequent writes. Thank you for thinking about it, though! Thanks as well for the updates, Ben > " > Does the XIP case mean that repeated firmware updates would have > potential to cause undue wear on the fixed flash cells that hold the > firmware image? If so, this might be noted in the security > considerations. > " > > Ciao > Hannes > > -----Original Message----- > From: Suit On Behalf Of Benjamin Kaduk > Sent: Thursday, November 19, 2020 12:10 PM > To: Brendan Moran > Cc: Russ Housley ; suit-chairs@ietf.org; suit ; The IESG ; draft-ietf-suit-architecture@ietf.org > Subject: Re: [Suit] Benjamin Kaduk's No Objection on draft-ietf-suit-architecture-14: (with COMMENT) > > Hi Brendan, > > Thanks for the extra reference and discussion about the timescale estimates for quantum computers and integer factorization. (And for accepting most of my other comments.) I see now how the factorization-by-annealing reference was intended to be used, and had not been paying close enough attention to know the 5640-qbit and doubling-every-two-years numbers for D-Wave. > > If I was going to suggest a change to the text, it would be quite small, perhaps something like "based on current research [quantum-factorization] and the trend in quantum annealing capacity". > > Thanks again, > > Ben > > On Wed, Nov 18, 2020 at 10:05:44PM +0000, Brendan Moran wrote: > > We will take on board the majority of these comments. > > > > WRT the PQC time horizon, quantum annealing attacks on RSA are dependent commercial quantum annealers. > > > > The paper in nature shows the factorisation of 376,289 in 94 qubits. In fact, other researchers have factored 1,005,973 with only 89 qubits [1]. With this second algorithm, characterised as O(log^2(N)), RSA-768 would require 147,454 qubits. D-Wave has shipped quantum computers with 5640 qubits already. They have a historical average of doubling the number of qubits every two years. Based on this trajectory, they should be shipping a quantum computer that can break RSA-768 in approximately 2030 (log_2(147454/5640)) = 4.7 => 9.4 years. RSA-2048, then, would be broken between 2 and 4 years later, and RSA-4096 a mere 2 years after that. > > > > This is a naive analysis. However, it is intended to show that a scalable general purpose quantum computer is not the only threat to current cryptographic techniques, that the time horizon is not long, and that urgent action is required to ensure that devices with long lifetimes account for EITHER cryptographic agility or quantum safety, preferably the latter, since quantum safe algorithms require much more data than classical asymmetric crypto and, therefore, require extra considerations, particularly when used in constrained IoT. > > > > Obviously, the hole in this analysis is that RSA is not common in IoT. I have not yet found equivalent research that shows how a quantum annealer could attack ECDSA or EDDSA. I assume that there are research teams working on this. We should prepare ourselves for the potential of that particular revelation. > > > > We have not gone into this detail in the architecture because it seems both orthogonal to the general discussion in the architecture, extremely time-sensitive, and extremely algorithm-sensitive. It will be an irrelevant prediction and analysis within a handful of years. > > > > Best Regards, > > Brendan > > > > [1] https://link.springer.com/article/10.1007/s11433-018-9307-1 > > > > > > > On 5 Nov 2020, at 09:38, Benjamin Kaduk via Datatracker wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-suit-architecture-14: No Objection > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Does the XIP case mean that repeated firmware updates would have > > > potential to cause undue wear on the fixed flash cells that hold the > > > firmware image? If so, this might be noted in the security > > > considerations. > > > > > > I am not sure that I have fully digested Bob Briscoe's detailed > > > review comments, but it seems like we may want to continue to > > > reflect on which portions of the architecture will be optional to > > > implement, and how we might indicate that in the document. > > > > > > I also made a pull request for some editorial nits at > > > https://github.com/suit-wg/architecture/pull/15 . > > > > > > Section 1 > > > > > > otherwise difficult. Firmware updates > > > for IoT devices are expected to work automatically, i.e. without user > > > involvement. Conversely, IoT devices are expected to account for > > > user preferences and consent when scheduling updates. Automatic > > > > > > I can't quite tell if the "Conversely" case is intending to refer to > > > IoT or non-IoT devices. > > > > > > The firmware update process has to ensure that > > > > > > - The firmware image is authenticated and integrity protected. > > > [...] > > > > > > - The firmware image can be confidentiality protected so that > > > attempts by an adversary to recover the plaintext binary can be > > > [...] > > > > > > Perhaps it's just because Bob Briscoe's comments are fresh in my > > > mind, but there seems to be something of a mismatch across these > > > texts -- we "have to ensure" that the firmware *is* authenticated > > > and integrity protected, but only that the image *can be* confidentiality protected. > > > Is it really the case that we can ensure that an update process *can > > > be* confidentiality protected, or is the confidentiality requirement > > > more of a requirement on the architecture than on actual deployment? > > > > > > While the IETF standardization work has been focused on the manifest > > > format, a fully interoperable solution needs more than a standardized > > > manifest. For example, protocols for transferring firmware images > > > and manifests to the device need to be available as well as the > > > status tracker functionality. Devices also require a mechanism to > > > discover the status tracker(s) and/or firmware servers, for example > > > using pre-configured hostnames or [RFC6763] DNS-SD. These building > > > blocks have been developed by various organizations under the > > > umbrella of an IoT device management solution. The LwM2M protocol is > > > one IoT device management protocol. > > > > > > We might put some forward references to things we do cover (like > > > status tracker(s)), and a reference for LwM2M as well. > > > > > > Section 3 > > > > > > Hence, the following components are necessary on a device for a > > > firmware update solution: > > > [...] > > > - a status tracker. > > > > > > Earlier we said that having the status tracker on the device was > > > fairly uncommon. > > > > > > Section 7 > > > > > > time horizon for quantum-accelerated key extraction. The worst-case > > > estimate, at time of writing, for the time horizon to key extraction > > > with quantum acceleration is approximately 2030, based on current > > > research [quantum-factorization]. > > > > > > I'm not sure that I see how the reference suports the "approximately > > > 2030" statement. > > > > > > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From nobody Mon Nov 30 23:07:47 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F153A0CC3; Mon, 30 Nov 2020 23:07:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-suit-information-model@ietf.org, suit-chairs@ietf.org, suit@ietf.org, Dave Thaler , dthaler@microsoft.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160680646119.13349.7940228703448501887@ietfa.amsl.com> Date: Mon, 30 Nov 2020 23:07:41 -0800 Archived-At: Subject: [Suit] Erik Kline's No Objection on draft-ietf-suit-information-model-08: (with COMMENT) X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 07:07:42 -0000 Erik Kline has entered the following ballot position for draft-ietf-suit-information-model-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 3.20 ] * Is "XIP" eXecute In Place? I don't see this in abbrev.expansion.txt so perhaps it's worth an expansion on first use.