[Last-Call] Secdir telechat review of draft-ietf-ipsecme-ikev2-multiple-ke-10

Sean Turner via Datatracker <noreply@ietf.org> Mon, 28 November 2022 17:52 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C118BC1526E7; Mon, 28 Nov 2022 09:52:10 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Sean Turner via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ipsecme-ikev2-multiple-ke.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166965793078.574.10550949979516489683@ietfa.amsl.com>
Reply-To: Sean Turner <sean@sn3rd.com>
Date: Mon, 28 Nov 2022 09:52:10 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/N0R7gpcRg2kOYtsv6SQiE5PKn-4>
Subject: [Last-Call] Secdir telechat review of draft-ietf-ipsecme-ikev2-multiple-ke-10
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2022 17:52:10 -0000

Reviewer: Sean Turner
Review result: Has Nits

Hi! Thanks for the well written draft. I really liked Appendix B that includes
the tried but discarded designs.

Issue worth discussing (and it might be a short discussion):

Are there any instructions that the DEs needs to make sure that this registry
is not populated with PQ-wanna-be Transforms? E.g., I show up my shiny new (and
supposedly) PQ resistant alg and the DE says ....

Nits:

The use of “we” is a style thing that I would change, but if the WG/IESG are
good with it I can get on board too.

s1.2, last para: “require such a requirement” is a bit awkward. How about “have
such a requirement” or “levy such a requirement”?

s2, hybrid: I think you might want to include some words by what you mean by
“hybrid”? Maybe as simple as copy some of the text from the 1st para of s3.1
forward, “when multiple key exchanges are performed and the calculated shared
key depends on all of them”.

s3.1, s/Note that with this semantics,/Note that with these semantics,

s4.1:

s/must/MUST in the DE instructions?
s/addition,any/addition, any

s5:

s/dwarfed/ with thwart or mitigate
s/the data need to remain/the data needs to remain

A.1:

s/as follows/as follows.
s/SKEYSEED(1)  …. )./SKEYSEED(1) … )
s/{SK_d(1) … SPIr)./{SK_d(1) … SPIr)

Is this missing:

 The updated SKEYSEED value is then used to derive the following
 keying materials

between these two lines:

 SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr)
 {SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) |
    SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)

A.4:s/a security association/an IKE SA