Re: [Iot-directorate] [Anima] Iotdir early review of draft-ietf-anima-constrained-voucher-12
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 22 July 2021 02:29 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iot-directorate@ietfa.amsl.com
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074EA3A33B7; Wed, 21 Jul 2021 19:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hxBzt5TEam3J; Wed, 21 Jul 2021 19:29:33 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C003A33B2; Wed, 21 Jul 2021 19:29:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CCDF0389F3; Wed, 21 Jul 2021 22:32:55 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MycKegQw0ng6; Wed, 21 Jul 2021 22:32:48 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D7206389F0; Wed, 21 Jul 2021 22:32:47 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 463051E8; Wed, 21 Jul 2021 22:29:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, iot-directorate@ietf.org, draft-ietf-anima-constrained-voucher.all@ietf.org, anima@ietf.org
In-Reply-To: <162670116630.5511.9611323774165158935@ietfa.amsl.com>
References: <162670116630.5511.9611323774165158935@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 21 Jul 2021 22:29:22 -0400
Message-ID: <25402.1626920962@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/oBxzMzRgQd01DIVYWo2hi1aQHZg>
Subject: Re: [Iot-directorate] [Anima] Iotdir early review of draft-ietf-anima-constrained-voucher-12
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 22 Jul 2021 02:29:39 -0000
Henk Birkholz via Datatracker <noreply@ietf.org> wrote: > Reviewer: Henk Birkholz Thank you for this review! > (0) Title > The title implies that this document defines a message or document called > 'Constrained Voucher Artifacts' used in 'Bootstrapping Protocols'. The first > sentence contradicts this by saying 'This document defines a protocol'. This > "IETF'ler Human" also suspects that "Voucher Artifacts" are kind of redundant, > but that was okay in RFC8366 so that seems to be okay here. https://github.com/anima-wg/constrained-voucher/issues/132 The title reflects a history that thought we'd write two documents. > (1) Abstract > The abstract requires more (concise!) context and outline of the general > problem so that context-specific terms used can be easily understood, e.g., > 'Pledge' or its relationship to 'owner'. Imagine the abstract being the only > thing visible in a document indexing and management system and phrase it as > such. The "new" CoAP protocol defined seems to be a complement to an HTTPS > protocol, which the reader has to guess is defined either by RFC8366 or BRSKI > (this is cleared up early in the Intro). Why is it not CoAPS, if its complement > is HTTPS? Ultimately, you shall not use references in an abstract and that is > the root cause for this need for guessing here, I think. https://github.com/anima-wg/constrained-voucher/issues/133 > (2) Introduction > OSCORE and EDHOC are suddenly used and not introduced. > Terms, such as 'Pledge' or 'Registrar' could be better introduced or it should > be very clearly stated that this memo cannot be used without a clear > understanding of other documents (and which documents that exactly are and > why). It is not very clear to the reader why YANG and SID are suddenly > appearing here (which again becomes pretty obvious when you read other > documents). In general, the Intro requires more context. I've tacked this onto the issue: https://github.com/anima-wg/constrained-voucher/issues/124 > (3) Overview of Protocol > It is not immediately clear what 'proximity' means here (the term is not listed > in the Terminology section). A quick recap of roles and interactions would not > hurt, I think, but that can also be addressed by adding more contextual text to > the Intro. "Most Pledges using these constrained": maybe just remove the > "these" - it made me read it as a back-reference to time-based vouchers. The > term "pinned" used here could benefit a from a tad bit more expositional text - > it is a term relevant to a lot of security aspects in this memo and deserves a > proper introduction. https://github.com/anima-wg/constrained-voucher/issues/134 > (4) Discovery, URIs and Content Formats > Maybe an example of EST and BRSKI URIs helps the reader to see the > difference/optimization more easily? The terms URI and URL or both used in this > section. Are they used dedicatedly with their distinct meanings or are they > used interchangeably? Sometimes the term 'end point' is also spelled > 'end-point'. Why is there a fall-back (as MAY) to Content-Format 50 for the > shorter URLs? https://github.com/anima-wg/constrained-voucher/issues/135 > (5) Extensions to BRSKI > 'CoRE Link Format parsing' is suddenly used and it is not clear here in the > context why avoiding that is useful. I am not sure that 'reconnect' is the > appropriate term to use when writing about resources available via a single UDP > port. https://github.com/anima-wg/constrained-voucher/issues/136 Reconnect because DTLS might get renegotiated, because we might go from COAP to COAPS, and it's just extra round trips. > (6) Extensions to EST-coaps > The example '/sen' for simple enrollment is used here, but not really > introduced in the document. Is that intentionally so? Yes, because it's in draft-ietf-ace-est-coaps. https://github.com/anima-wg/constrained-voucher/issues/137 > (7) Pledge Extensions > '/att' is introduced here and it might not be obvious to a reader where that > comes from and what it exactly represents. Maybe a small example for "it MUST > use the Subject Distinguished Name fields from its IDevID unmodified." would > help here? Is '/crts' the short-name for '/cacerts'? So - in general, maybe > there should be a complete list of short-names used or are these intentionally > just used as examples? https://github.com/anima-wg/constrained-voucher/issues/138 > (8) Registrar Extensions > "for operational or security reasons" - that could be a topic for the TBD in > the Security Considerations. Agreed. > (9) BRSKI-MASA Protocol > Some of the consideration about "CoAPS for the BRSKI MASA is deemed > unrealistic" can probably also fuel the Security Considerations. https://github.com/anima-wg/constrained-voucher/issues/139 > (10) Registrar Identity Selection and Encoding > 'which participate' -> 'that participate' fixed in my copy. > (11) MASA Pinning Policy > Maybe explicitly highlight that in the case of the nonce-less vouchers, the > makeup of the x5bag provides the knobs and dials to exactly influence which > certificate will be pinned. That is only expressed implicitly, I think, or I > did not get the meaning of the text properly. https://github.com/anima-wg/constrained-voucher/issues/140 > (12) Pinning of Raw Public Keys > "However, if the Pledge is known to also support RPK pinning and the MASA > intends to pin the Registrar's identity (not a CA), then MASA SHOULD pin the > RPK (RPK3 in Figure 2) of the Registrar instead of the Registrar's End-Entity > certificate to save space in the voucher.": why is that not a MUST? What are > the consequences, if that is not done as highlighted? https://github.com/anima-wg/constrained-voucher/issues/141 -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Iot-directorate] Iotdir early review of draft-ie… Henk Birkholz via Datatracker
- Re: [Iot-directorate] [Anima] Iotdir early review… Michael Richardson