Re: [secdir] Secdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-28

Benjamin Kaduk <kaduk@mit.edu> Fri, 18 October 2019 03:48 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 0F63B1201DC for <secdir@ietfa.amsl.com>; Thu, 17 Oct 2019 20:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZhPbQ8ERJkbB for <secdir@ietfa.amsl.com>; Thu, 17 Oct 2019 20:48:06 -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 1EDAB120052 for <secdir@ietf.org>; Thu, 17 Oct 2019 20:48:05 -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 x9I3lx4D012638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Oct 2019 23:48:02 -0400
Date: Thu, 17 Oct 2019 20:47:59 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christian Huitema <huitema@huitema.net>
Cc: secdir@ietf.org
Message-ID: <20191018034759.GC43312@kduck.mit.edu>
References: <157094241575.1368.11692727174528463365@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <157094241575.1368.11692727174528463365@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/WVWB9MNvFqkHGLGNyD-ir_agWMY>
Subject: Re: [secdir] Secdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-28
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, 18 Oct 2019 03:48:08 -0000

Hi Christian,

Thanks for taking the time to re-review this epic.  It's reassuring to have
the extra opinion that the document is much improved!  I asked the authors
to respond to your few remaining comments and am holding a Discuss ballot
for a couple of boring points about clarity of protocol details.

-Ben

On Sat, Oct 12, 2019 at 09:53:35PM -0700, Christian Huitema via Datatracker wrote:
> Reviewer: Christian Huitema
> 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.
> 
> The summary of the review is ready with nits.
> 
> The draft-28 is much improved from the version that I originally reviewed, or
> even from the intermediate version 20. The issues flagged in the original
> review are now addressed. The draft now develops options for "nonceless
> vouchers", which allows for offline onboarding scenario and addresses one of
> the concerns expressed in my initial review. It also develops a TOFU option for
> MASA servers, which has different security properties than the initial design.
> That may be a useful mode of operation, and the related security issues are
> discussed in subsection 11.4 of the security consideration sections.  Draft 28
> addresses scenarios like "death of a manufacturer" that were flagged in the
> first reviews. Generally, I find the revised security consideration section
> much more developed and comprehensive than in the original drafts.
> 
> Draft 28 adds an extended privacy consideration section, which is welcome. On
> the other hand, the authors may consider toning down the commentary text in
> section 10.3, "The so-called "call-home" mechanism that occurs as part of the
> BRSKI-MASA connection standardizes what has been deemed by some as a sinister
> mechanism for corporate oversight of individuals." That text was already in
> draft-20, but feels a bit too petulant for standard track RFC.
> 
> I flagged a couple of technical nits:
> 
> I have a minor concern with the text on TLS usage in section 5.1 and 5.2. In
> section 5.1, BRSKI-EST TLS establishment details, I read "Use of TLS 1.3 (or
> newer) is encouraged. TLS 1.2 or newer is REQUIRED." Does that mean that
> BRSKI-EST TLS servers MAY reject connection attempts using a TLS version lower
> than 1.2, or maybe that pledges SHOULD refuse connections if the server tries
> to negotiate a TLS version lower than 1.2? We have experience in other
> deployments that even "low end" vendors will not cheap lower security solutions
> if that leads to interop failures, and that having at least some
> implementations being strict in what they accept is a good way to raise the bar
> for everybody.  Same issue in section 5.2, regarding BRSKI MASA connections.
> 
> In section 5.4.1, "This document does not make a specific recommendation"
> (regarding whether to use public PKI, DANE, or pinned certificates for MASA
> authentication. That's probably fine from a security point of view, but the
> absence of at least one recommended solution ay well end up causing interesting
> interoperability issues.
> 
> Editorial Nits:
> 
> In section 1.4, the text says "The major intended beneficiary is that it
> possible to use the credentials deployed by this protocol to secure the
> Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane])." I
> think you mean "benefit" instead of "beneficiary".
> 
> In section 2.3.1, the text says "The serialNumber fields is defined in
> [RFC5280], and is a SHOULD field in [IDevID]." I understand that you mean that
> according to [IDevId] the field SHOULD be present, but calling that a "SHOULD
> field" is jargon.
> 
> In section 7.4.1, I read that "A MASA has the option of not including a nonce
> is in the voucher, and/or not requiring one to be present in the
> voucher-request." The "is in" looks like some kind of typo.
> 
> In section 10.2, typo, "arbtirary" for "arbitrary".
> 
>