[Iot-directorate] Iotdir last call review of draft-ietf-drip-arch-22
Thomas Fossati via Datatracker <noreply@ietf.org> Sun, 27 March 2022 17:44 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: iot-directorate@ietf.org
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 777DA3A07A9; Sun, 27 Mar 2022 10:44:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Thomas Fossati via Datatracker <noreply@ietf.org>
To: iot-directorate@ietf.org
Cc: draft-ietf-drip-arch.all@ietf.org, last-call@ietf.org, tm-rid@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164840309027.4996.16025423500440919013@ietfa.amsl.com>
Reply-To: Thomas Fossati <thomas.fossati@arm.com>
Date: Sun, 27 Mar 2022 10:44:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/ayhvjbZajmZv6TZuGCfH9LcUu7I>
Subject: [Iot-directorate] Iotdir last call review of draft-ietf-drip-arch-22
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Mar 2022 17:44:51 -0000
Reviewer: Thomas Fossati Review result: Ready with Issues This is a great document and fun to read. Thank you authors! I have tried to highlight a few small things that could be articulated a bit more from an IoT perspective but overall I have no major concerns with it, except a tangential thing around the document intended status (see "Issues" below.) # Issues * The charter says: "the WG will propose a standard document that describes the architecture […]" but the status is informational. I am pretty sure informational should be appropriate, but highlighting a potential disconnect. # Comments * In some IETF circles (e.g., RATS & TEEP) "attestation" has a precise meaning, which is quite distinct from the DRIP definition "[…] normally used when an entity asserts a relationship with another entity". Specifically, unless the signing key is derived from the measured boot state (a la DICE), or the claims are of a certain kind, the process that this doc names "attestation" is not what is meant usually. => Maybe add a few words to Section 2.2 to clarify the distinction between DRIP attestation and RATS's, e.g., by adding a disclaimer similar to that already associated with DRIP certs. * Apropos "remote attestation", I am wondering whether, given the type of endpoints considered in the architecture - and in particular provided their increased exposure to physical compromise, and the potentially large impact on the overall system and beyond - the architecture should provide explicit channels for securely conveying the verification of the installed and booted firmware (as well as any other relevant trust metrics)? * I haven't read the rest of the DRIP docs, so I am not sure why is EdDSA specifically mentioned in Section 3.2.? Is this a requirement or just an example? I guess the latter, but checking just in case. And apropos that, in light of fault attacks on deterministic ECDSA and EdDSA [0] that are potentially easier to carry out against UAs (BTW, how cool is a fault attack w/ private key exfiltration carried out by a chasing drone?) maybe it's worth adding to the security considerations some words around physical attacks and their impact on the choice of signature algorithms? * It'd seem that, given the very low bandwidth, DoS (as well as Denial of View) attacks on communication involving the UA should be quite easy to mount? Maybe worth spending some words on the argument to describe what the threats are and which mitigations are available. * This is a question more than anything else: given the constrained nature of UAs, I was wondering whether it is envisaged that the end-to-end network path will be realised with the use of more capable (trusted) proxy nodes? If so, there may be a few security and privacy considerations to be added. # Nits * AAA is usually intended as "Authentication, Authorization, and Accounting" (see also [1]), whereas here it's got four new A's: Attestation, Access Control , Attribution, Audit :-) => Maybe change it to 7A, A7, AAA+ or similar? * In Section 2.1, the following terms are already in the most recent "RFC Editor Abbreviations List" [1] and can be removed: * EdDSA * HIP * HIT * HI * Some typographic inconsistency around Bluetooth: Is it 4 or 4.x? 5 or 5.x? => Stick to one format. (Also maybe add an explicit reference to the Bluetooth specs.) [0] https://eprint.iacr.org/2020/803 [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt
- [Iot-directorate] Iotdir last call review of draf… Thomas Fossati via Datatracker
- Re: [Iot-directorate] Iotdir last call review of … mohamed.boucadair
- Re: [Iot-directorate] Iotdir last call review of … Stuart W. Card
- Re: [Iot-directorate] Iotdir last call review of … Thomas Fossati
- Re: [Iot-directorate] [Drip] Iotdir last call rev… Robert Moskowitz
- Re: [Iot-directorate] Iotdir last call review of … shuai zhao
- Re: [Iot-directorate] Iotdir last call review of … Thomas Fossati