Re: [secdir] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

Russ Housley <housley@vigilsec.com> Tue, 08 January 2019 17:40 UTC

Return-Path: <housley@vigilsec.com>
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 E74C3130F28 for <secdir@ietfa.amsl.com>; Tue, 8 Jan 2019 09:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 6zHE12BtM-is for <secdir@ietfa.amsl.com>; Tue, 8 Jan 2019 09:40:07 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C078D130F27 for <secdir@ietf.org>; Tue, 8 Jan 2019 09:40:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 610EA300AA2 for <secdir@ietf.org>; Tue, 8 Jan 2019 12:15:31 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J9PEYMsd-RPu for <secdir@ietf.org>; Tue, 8 Jan 2019 12:15:29 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id 4743F30005C; Tue, 8 Jan 2019 12:15:29 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <154695697211.25494.5342366287090150478@ietfa.amsl.com>
Date: Tue, 8 Jan 2019 12:33:45 -0500
Cc: IETF SecDir <secdir@ietf.org>, spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <38C4C1A8-42E9-4F50-B4F1-356909D81AC9@vigilsec.com>
References: <154695697211.25494.5342366287090150478@ietfa.amsl.com>
To: Adam Montville <adam.w.montville@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/JtEpvA9Al26KazF1gLUK0AK9bv4>
Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03
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: Tue, 08 Jan 2019 17:40:09 -0000


> On Jan 8, 2019, at 9:16 AM, Adam Montville <adam.w.montville@gmail.com>; wrote:
> 
> Reviewer: Adam Montville
> Review result: Ready
> 
> This draft is ready. It's a clever (though not foolproof) way to prime the pump
> for root certificate updates. I'm not an ASN.1 expert, so I can't really opine
> on the structure in Section 3, but from what I can tell it looks sane.
> Operational considerations seems sane. Security considerations rely on those
> from RFC5280, and additionally addresses: 1) analysis before the
> next-generation root certificate is released, 2) key strength considerations
> (equal or greater than current), 3) unforeseen cryptoanalytic advances, 4)
> typical hash pre-image attacks, and 5) early release of the next-generation
> public key.
> 
> One area in the security considerations that could be enhanced is the
> recommended action to take in the case of an early next-generation public key
> release. The language in the draft states: "The second transition occurs when
> the Root CA is confident that the population of relying parties have completed
> the first transition, and it takes the Root CA to the freshly generated key
> pair." The question that came to mind was: What might bring about such
> confidence? I'm not sure that it's possible to generalize an answer to that
> question, however.

Adam:

Thanks for the review.

I can assure you that I compiled the ASN.1 module.

This paragraph is the result of the discussion in the LAMPS WG session in London.  The timing is not that critical if the oldWithNew and newWithOld advice from RFC 2510 (updated to RFC 4210) is followed.  This is talked about in Section 5 on "Operational Considerations".  I have an update to the paragraph in Section 5 based on other comments:

   Guidance on the transition from one trust anchor to another is
   available in Section 4.4 of [RFC4210].  In particular, the oldWithNew
   and newWithOld advice ensures that relying parties are able to
   validate certificates issued under the current Root CA certificate
   and the next generation Root CA certificate throughout the
   transition.  Further, this advice avoids the need for all relying
   parties to make the transition at the same time.

Russ