[lamps] Starting work to CAA and SHAKE

Russ Housley <housley@vigilsec.com> Fri, 15 September 2017 19:43 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA5D133207 for <spasm@ietfa.amsl.com>; Fri, 15 Sep 2017 12:43:11 -0700 (PDT)
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] 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 N50zkIrtNe8w for <spasm@ietfa.amsl.com>; Fri, 15 Sep 2017 12:43:10 -0700 (PDT)
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 87528133074 for <spasm@ietf.org>; Fri, 15 Sep 2017 12:43:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DF812300582 for <spasm@ietf.org>; Fri, 15 Sep 2017 15:43:06 -0400 (EDT)
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 M0qtm2ed5YP0 for <spasm@ietf.org>; Fri, 15 Sep 2017 15:43:06 -0400 (EDT)
Received: from [5.5.33.163] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id D2BD1300265 for <spasm@ietf.org>; Fri, 15 Sep 2017 15:43:05 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <D774A9B1-F765-4BDA-9D78-D584B4B0EFF8@vigilsec.com>
Date: Fri, 15 Sep 2017 15:43:01 -0400
To: spasm@ietf.org
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/UwmV9M26xL_n1Jtgh0BofZCdjCg>
Subject: [lamps] Starting work to CAA and SHAKE
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Sep 2017 19:43:11 -0000

I have been discussing the recharter with EKR, and he agrees that we should get started on this work even though the LAMPS re-charter is blocked on a bit of process.

Having completed the S/MIME 4.0 specifications and updates to support i18n email addresses in PKIX certificates, the LAMPS WG is now ready to work on two additional topics:

1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.

Other topics can be considered when these two are progressing.


CAA

RFC 6844 describes the mechanism by which CAA records relating to a domain are discovered.  Implementation experience has demonstrated an ambiguity in the current processing of CNAME and DNAME records during discovery.  Subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the current approach.  We have seen at least two individual drafts on this topic.  I would like to have the WG adopt a rfc6844bis as a starting point.


SHAKE

Unlike the previous hashing standards, the SHA-3 functions are the outcome of an open competition.  They have a clear design rationale and have received a lot of public analysis, resulting in great confidence that the SHA-3 family of functions are very secure.  Also, since the design of the SHA-3 functions use a very different construction from the SHA-2 functions, they offer an excellent alternative to the SHA-2 family
of functions.  In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits.  We have not seen any individual drafts on this yet.  It seems to me that one draft is needed for PKIX and another draft is needed for CMS and S/MIME.  Is anyone willing to work on them?

Russ