[regext] Secdir last call review of draft-ietf-regext-epp-eai-12

Chris Lonvick via Datatracker <noreply@ietf.org> Mon, 13 June 2022 00:48 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B5AC157B35; Sun, 12 Jun 2022 17:48:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Chris Lonvick via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-regext-epp-eai.all@ietf.org, last-call@ietf.org, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165508129253.14230.7213126475579121692@ietfa.amsl.com>
Reply-To: Chris Lonvick <lonvick.ietf@gmail.com>
Date: Sun, 12 Jun 2022 17:48:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/N1SaJGKr42X6kcO4tFxBFbrWzCI>
Subject: [regext] Secdir last call review of draft-ietf-regext-epp-eai-12
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2022 00:48:12 -0000

Reviewer: Chris Lonvick
Review result: Has Issues


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

The summary of the review is that it has issues.

The document is well written and the Security Considerations seems appropriate.
However, there is insufficient guidance given regarding when the EAI functional
extension is negotiated, but when the server cannot satisfy the required
obligations. The specification says that when the client and server negotiate
the EAI functional specification that, "implies the possibility to process the
EAI address". The draft needs to specify what happens if the client and server
negotiate the EAI functional extension, but when the server cannot fulfill its
obligations to provide the required information, or when the client cannot
process the received information.

This may be easily fixed by saying in the specification that the server will
only accept the negotiation if it can (MUST) provide the required information
specified in section 5.3.1 and that the client can (MUST) accept and act upon
that received information. The specification should also go on to say what MUST
happen if those conditions are not met.

Best regards,