[saag] LAMPS

Russ Housley <housley@vigilsec.com> Sat, 13 March 2021 22:37 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA993A10DA for <saag@ietfa.amsl.com>; Sat, 13 Mar 2021 14:37:59 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_NONE=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 pYmep1WUT_A7 for <saag@ietfa.amsl.com>; Sat, 13 Mar 2021 14:37:56 -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 7D2063A10D8 for <saag@ietf.org>; Sat, 13 Mar 2021 14:37:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 034B5300B78 for <saag@ietf.org>; Sat, 13 Mar 2021 17:37:54 -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 CdvzGi3qY1DD for <saag@ietf.org>; Sat, 13 Mar 2021 17:37:52 -0500 (EST)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 52DE13001A8 for <saag@ietf.org>; Sat, 13 Mar 2021 17:37:52 -0500 (EST)
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 12.4 \(3445.104.17\))
Message-Id: <FD86B461-96C1-4C83-B717-8DA78A72FA66@vigilsec.com>
Date: Sat, 13 Mar 2021 17:37:52 -0500
To: IETF SAAG <saag@ietf.org>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/4YAZsGJlEHIGNDzvRhhVATpX9dQ>
Subject: [saag] LAMPS
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Mar 2021 22:37:59 -0000

S/MIME header protection (draft-ietf-lamps-header-protection):  The way that messages that include header protection are displayed by existing implementations a concern, and DKG asked for assistance gather this information, especially for mail clients that are not freely available.  One of the example messages is showing as an invalid signature, and DKG asked for assistance in finding our why that is the case.  The examples are available at https://header-protection.cmrg.net/.

Three CMP-related documents: CMP Algorithms (draft-ietf-lamps-cmp-algorithms), CMP Updates (draft-ietf-lamps-cmp-updates), and Lightweight CMP Profile (draft-ietf-lamps-lightweight-cmp-profile): The role of the Registration Authority (RA) was discussed briefly, with a focus on when the certificate needed to include the id-kp-cmcRA from RFC 6402.

Guidance on End-to-End E-mail Security (draft-dkg-lamps-e2e-mail-guidance):  The LAMPS WG needs to re-charter to progress this work.

Verification-Friendly ECDSA (draft-struik-lamps-verification-friendly-ecdsa):  A speed-up for ECDSA was described.  If the verifier knows that the speed-up was used, they get a benefit.  If the verifier is unaware of the speed-up, the usual technique will still validate the signature. A new algorithm identifier would mean that verifiers would treat it as an unknown algorithm, even though the signature validation would work using the slower, existing technique.  A non-critical certificate extension could provide an indication that the speed-up is available, this would be ignored by implementation that do not support the speed-up, and they would still be able to validate the signature.  There was some concern around patents, and it seems that all of them will expire in the next four years.  It is expected that it will take more than four years to complete the specification ad get real deployment.  Other people question whether it is worth a speed-up for ECDSA when post-quantum algorithms are going to be standardized in the next few years.  No decision was reached, and the discussion will continue on the mail list.