[secdir] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 12 July 2022 23:29 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0698C1594AE; Tue, 12 Jul 2022 16:29:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-uta-rfc7525bis.all@ietf.org, last-call@ietf.org, uta@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165766858084.5251.12485129434316295805@ietfa.amsl.com>
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Date: Tue, 12 Jul 2022 16:29:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rHQnO7m9cVqwyOTk5QLVB1SU8WA>
Subject: [secdir] Secdir telechat review of draft-ietf-uta-rfc7525bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2022 23:29:40 -0000

Reviewer: Benjamin Kaduk
Review result: Ready

I looked over the updates from -07 to -09, and they all look good.
I recognize that not all of my previous comments resulted in any text
changes, and appreciate that they were given consideration and the
conscious choice made to not act.  I'd also like to thank the editors
for their efforts to proactively tag me in the github discussion that my
earlier review triggered, and I apologize for not keeping up with that
traffic as it came in.

I do have one comment on the new text:

Section 3.9

Thanks for adding the section on mulit-server deployment, that's a great
addition!  In the (first) "multiple services" case, we might also want
to mention that the protection of credentials (certificate private keys)
is a shared attack surface across services, so when we say "provide
equivalent levels of security" we might clarify that we consider both
the TLS configuration and the protections against server compromise as
being relevant.  (Even if the two services do not share
credentials/keys, which would itself be best practice, since they are on
the same domain name the credentials for one are likely to be usable for
impersonating the other.  Only if technologies like X.509 EKUs and/or
certificate extensions are used to restrict both certificates'
applicability does this risk disappear, and I'm reluctant to propose
adding extensive discussion of these topics to the draft at this stage
in the process.)


I'll also repeat one comment from my earlier review to make it more visible
to the ADs.  I acknowledge that the authors already responded to it and
that the same reply continues to apply; I do not expect that repeating my
statement will be any more convincing than it was the first time.

Section 3.1.1

   *  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
      negotiate TLS version 1.2 over earlier versions of TLS.
      [...]
   *  Implementations SHOULD support TLS 1.3 [RFC8446] and, if
      implemented, MUST prefer to negotiate TLS 1.3 over earlier
      versions of TLS.

It's very disappointing to me to see that we label a TLS 1.3-only
implementation as non-compliant with the BCP for TLS usage; such an
implementation is more secure than a joint 1.2+1.3 implementation.
That said, I assume that the WG discussed this topic extensively and
it seems somewhat unlikely that I have any new contributions to that
discussion.