[Sframe] Secdir last call review of draft-ietf-sframe-enc-06

Carl Wallace via Datatracker <noreply@ietf.org> Sat, 17 February 2024 12:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sframe@ietf.org
Delivered-To: sframe@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF81C14F689; Sat, 17 Feb 2024 04:09:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carl Wallace via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-sframe-enc.all@ietf.org, last-call@ietf.org, sframe@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170817178876.39035.15829993379318343179@ietfa.amsl.com>
Reply-To: Carl Wallace <carl@redhoundsoftware.com>
Date: Sat, 17 Feb 2024 04:09:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/KK2sm31k5GNnczm2UZOUS0ERf18>
Subject: [Sframe] Secdir last call review of draft-ietf-sframe-enc-06
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Secure Media Frames <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Feb 2024 12:09:48 -0000

Reviewer: Carl Wallace
Review result: Has Nits

This is a very well written document. A few minor comments are below.

In section 4.3, the language for Key or Key Length and Counter or Counter
Length is a little difficult to parse. Dropping the commas around "minus one"
would help or maybe splitting into two sentences. "If the X flag is set to 0,
this field contains the Key ID. Else, this field contains the key ID length
minus one."

In 4.4, the section title should probably be Encryption Scheme.

In 4.4.1, the first sentence of the fifth paragraph should start "A given
base_key MUST NOT be used...". There may be a few other places where "key" is
used where "base_key" would be more clear (like the "Adding a key for sending",
etc. in the example API, in the title of section 4.4.1, etc.).

In 4.4.2, there is a typo - encrytion.

Throughout, it may be worth indicating which pseudocode method names are not
expanded upon in the draft, i.e., encode_big_endian, encode_sframe_header.
Maybe prepend with an underscore and note that practice.

In table 1, given Nk is used as a table header, it may be best to introduce the
composite key notion in section 4.4 (even if only via a forward reference to
4.5.1). It's a bit confusing on a first read to see 48 for the first three rows
on a first read. Maybe defining Nka in 4.4.4 would be sufficient.

In section 9.1, if only one sender can use a base_key for encryption, why is
the KID noted as important to avoiding reuse of (base_key, KID, CTR)
combinations? Is the assignment of KIDs to ensure KID values are unique across
set of senders in addition to unique base_key values?