[Anima] Secdir last call review of draft-ietf-anima-constrained-join-proxy-14

Mališa Vučinić via Datatracker <noreply@ietf.org> Wed, 20 September 2023 13:04 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED60C15C523; Wed, 20 Sep 2023 06:04:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mališa Vučinić via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: anima@ietf.org, draft-ietf-anima-constrained-join-proxy.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <169521508411.8385.14448275184156573646@ietfa.amsl.com>
Reply-To: Mališa Vučinić <malisa.vucinic@inria.fr>
Date: Wed, 20 Sep 2023 06:04:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/hVeKdJF_OXhKCtgzfiN4kLpJZxk>
Subject: [Anima] Secdir last call review of draft-ietf-anima-constrained-join-proxy-14
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2023 13:04:44 -0000

Reviewer: Mališa Vučinić
Review result: Has Nits

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
comments.

I have previously reviewed this document at its -09 version. The document reads
better now and I thank the authors for making the changes. I still have one
discussion point to raise.

Section 4.3 says "The Join Proxy SHOULD encrypt this context with a symmetric
key known only to the Join Proxy. This key need not persist on a long term
basis, and MAY be changed periodically. The considerations of Section 5.2 of
[RFC8974] apply."

Section 5.2 of RFC8974 recommends integrity and replay protection of the
transported state. Security Considerations section of this document references
this and recommends integrity and replay protection as well. However, the
example in Section 4.3 talks about a single AES128 block being encrypted and
transported as context. This is somewhat inconsistent. I would recommend
discussing integrity and replay protection as part of the normative language in
Section 4.3 and providing an example following that.

Nits:
- Section 4.2: Introduce acronym JPY upon first usage
- Section 4.3.1: “The pledge_content field must be provided as input to a DTLS
library”. Field name is “content”. - Section 7: “When the communication between
JOIN Proxy...". s/JOIN/Join