[secdir] Secdir last call review of draft-ietf-emu-eap-tls13-11

Kyle Rose via Datatracker <noreply@ietf.org> Wed, 28 October 2020 00:11 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 852B93A098D; Tue, 27 Oct 2020 17:11:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kyle Rose via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: emu@ietf.org, last-call@ietf.org, draft-ietf-emu-eap-tls13.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160384386950.10450.5930216784938121668@ietfa.amsl.com>
Reply-To: Kyle Rose <krose@krose.org>
Date: Tue, 27 Oct 2020 17:11:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0YbknIb_snAnlcOVUDnUSR7Upe4>
Subject: [secdir] Secdir last call review of draft-ietf-emu-eap-tls13-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 28 Oct 2020 00:11:10 -0000

Reviewer: Kyle Rose
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
last call comments.

This document is ready with nits.

The purpose of this document is to update the TLS method of EAP to accommodate
the changes to TLS in 1.3: in this, it appears to be complete and to have been
thoroughly vetted. I have two nits and a high-level suggestion:

* The introduction at one point says "Privacy is mandatory". Later in the
document it becomes clear what is meant by this, but at this point in the
document "privacy" is somewhat of a Rorschach test. It clearly doesn't mean
that repeated EAP requests from the same IP will be unlinkable, for instance.
What appears to be meant here is that encryption of the client certificate
prevents linkability via passive surveillance. Say that instead.

* Expand NAI into "Network Access Identifiers", with the appropriate
informative reference, at its first use, not halfway through the document.

* My high-level suggestion for this document is to be forward-looking in how
you specify the relationship of EAP to TLS. Expect there to be a TLS 1.4 (or
2.0) and beyond, and specify this protocol using standardized TLS interfaces
only, with the rest of the protocol (including the specific handshake messages)
treated as a black box. This may or may not have been possible in the pre-TLS
1.3 era, but it is certainly possible to do so now. At best, no normative
changes will be required; at worst, the size of the update to the EAP RFC will
be minimized.