Re: [secdir] Secdir last call review of draft-ietf-emu-eaptlscert-06

Benjamin Kaduk <kaduk@mit.edu> Fri, 30 October 2020 03:04 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CC33A0D67; Thu, 29 Oct 2020 20:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ5si9zKwcLc; Thu, 29 Oct 2020 20:04:26 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465C33A0D66; Thu, 29 Oct 2020 20:04:25 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09U34F8w028039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Oct 2020 23:04:20 -0400
Date: Thu, 29 Oct 2020 20:04:15 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-emu-eaptlscert.all@ietf.org, emu@ietf.org
Message-ID: <20201030030415.GE39170@kduck.mit.edu>
References: <160401318284.11167.6795105917637378641@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <160401318284.11167.6795105917637378641@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/dTI1lu-OCT6rLqRpwzKDXFKdfpo>
Subject: Re: [secdir] Secdir last call review of draft-ietf-emu-eaptlscert-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 30 Oct 2020 03:04:28 -0000

Hi Stefan,

Thanks for the review; it raises some good topics.
Replying on a couple points...

On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatracker wrote:
> Reviewer: Stefan Santesson
> Review result: Has Nits
> 
> The document in general is good and well written.
> 
> Some nits needs attention before publication as the general review also points
> out. Ex in the abstract "This document looks at the this problem"
> 
> Some abbreviations needs to be spelled out at first usage, such as MTU (Maximum
> Transmission Unit)

MTU may actually be okay; per
https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as
"well-known" and does not always need to be expanded.

> On the content itself I have two questions:
> 
> - Wouldn't it be relevant to also discuss the risks with regard to introduction
> of quantum safe crypto, if that leads to significantly increased key sizes? It
> could be troublesome if transition to a safer crypto is made impossible due to
> size limitations. - Would it be relevant to discuss usage of AIA extension as
> means of possibly excluding intermediary certs from the path as they could be
> located using AIA?
> 
> Finally, I agree with the general review that this document reference quite
> some work in progress. If this document is to be published before these
> referenced works are concluded, are there alternatives to make the same point?

They seem to mostly be informative references, and so would not require us
to hold publication of this document.  It is probably still worth
considering if there are alternatives anyway, though.

-Ben