Re: [lamps] LAMPS Re-charter

Rene Struik <rstruik.ext@gmail.com> Mon, 22 March 2021 15:03 UTC

Return-Path: <rstruik.ext@gmail.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 C06D73A1763 for <spasm@ietfa.amsl.com>; Mon, 22 Mar 2021 08:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zzFcRZSDHa0s for <spasm@ietfa.amsl.com>; Mon, 22 Mar 2021 08:03:32 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2332D3A1762 for <spasm@ietf.org>; Mon, 22 Mar 2021 08:03:32 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id j7so12530298qtx.5 for <spasm@ietf.org>; Mon, 22 Mar 2021 08:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=B/pJG+03ufDUSYh5rovqPmiIleitfMlVxzHqy1y8VM4=; b=p+h/h18NMx4ag7YtfZdyI/ePst/CPznGTQUNbvS/OtDbE/WLNfgBBPqHAIuau3Ephc UemAPyE+1kVhqw1sfGrUvCQCELiTjxPLgj9oxqcte5FSVy98L/6EvaiqgAF87iXsoAiN UxchRXa6Fu1byP748EcVVfGSeVICNr+nq824n5srzMxQ5WGHLtgyVuEGpZYv6m2u/Dkg aNdvaFK6+pOTaMDeRSuV8VgrpDifpPdGx39UHJG3aDUgH7gFFJL3MIBFglfR8Kq+8b0W JI/BZ3xr69qQrgxdCxrmZu2fLgzNkQQ6TNK/K3+9aXBq+G0DG2R7AdzEXjSFmcvc7s/a qa6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=B/pJG+03ufDUSYh5rovqPmiIleitfMlVxzHqy1y8VM4=; b=EJYE5OU+gTyg+EVtWEK2FynOkJJXnrtFHVJ9HNfwlRqBEeGELcfKhZR/jP8sFTmWMn 1LWughtOvcW/s4r4OD5B3f53iylyWF903EE3VCRSR3HRKiZIkpmFUfh0NgjE/u5SNaIy 1wJwir/GyUmZikr3ruJUOJK8wgCSX6Jj6rTTCtefzUhc+hhhglhkpXZECqGDpIxhHVwv dc1ZqLJld/RkVoHDXMqn3phadY6sc3Sf6EAWvLyqPB9KN+qXjKJ+WyJ08e6J8hme81x0 XcRmzo5kd3/RWfR8i9gzhcdUtdkQo/ZA5j25RJg0UZ2XPAPryD8bTVSYvn5LkN9NJsxZ uHcA==
X-Gm-Message-State: AOAM532tulyJRg7hC7uELZVc5YaVucOHjFfArvz3bzf3mf4wCWCJLtQW 2Bc+dDbvVMIScv8adscL6iwZCR5ZURE=
X-Google-Smtp-Source: ABdhPJy6gsGrTm1x/0cpMDmXslPYTQSmU3abllHvlE5EYTWjgFYOmEUSgfU/srMSDk05mTSOAchx3g==
X-Received: by 2002:aed:2143:: with SMTP id 61mr331882qtc.136.1616425409937; Mon, 22 Mar 2021 08:03:29 -0700 (PDT)
Received: from ?IPv6:2607:fea8:8a0:1397:4c87:8ab2:a7e5:e99c? ([2607:fea8:8a0:1397:4c87:8ab2:a7e5:e99c]) by smtp.gmail.com with ESMTPSA id f8sm11085654qkk.23.2021.03.22.08.03.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Mar 2021 08:03:28 -0700 (PDT)
To: Russ Housley <housley@vigilsec.com>, LAMPS <spasm@ietf.org>
References: <5A22DF7B-BCA5-42F6-BB95-D4F70FDB1996@vigilsec.com> <951CAF0F-7461-4057-B95E-D1F6CAE61D02@vigilsec.com> <4c18a9982cc94df2952d7b2cbae89d99@cert.org> <7B82765F-9C7A-4C4D-B115-A2835B44E6D6@vigilsec.com> <b3fdb1ac051b4ae0ad748782daebead2@cert.org> <ACE141CD-B0B7-45D3-B54F-BE25275A0D25@vigilsec.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <29f2b6c9-d7fe-0aa5-4509-d10279a2d902@gmail.com>
Date: Mon, 22 Mar 2021 11:03:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <ACE141CD-B0B7-45D3-B54F-BE25275A0D25@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------3189EF0F979905E0AF5DACF6"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/G4JCYcpAShpUma_o-DloAtcTuqo>
Subject: Re: [lamps] LAMPS Re-charter
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Mar 2021 15:03:35 -0000

Hi Russ, colleagues:

Please find below my comments/reflections on the draft charter text.

Best regards, Rene

On 2021-03-17 6:26 p.m., Russ Housley wrote:
> After listening to the LAMPS re-charter comments, I think this 
> captures a way forward.  The PQC milestones do not have a "send to the 
> IESG" part.  The idea is that we would add those when NIST winners get 
> announced.
>
> Thoughts?
>
> Russ
>
> = = = = = = = = =
>
> The PKIX and S/MIME Working Groups have been closed for some time. Some
> updates have been proposed to the X.509 certificate documents produced
> by the PKIX Working Group and the electronic mail security documents
> produced by the S/MIME Working Group.
>
> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
> Group is chartered to make updates where there is a known constituency
> interested in real deployment and there is at least one sufficiently
> well specified approach to the update so that the working group can
> sensibly evaluate whether to adopt a proposal.
>
> The LAMPS WG is now tackling these topics:
>
> 1. Specify the use of short-lived X.509 certificates for which no
> revocation information is made available by the Certification Authority.
> Short-lived certificates have a lifespan that is shorter than the time
> needed to detect, report, and distribute revocation information.  As a
> result, revoking short-lived certificates is unnecessary and pointless.
>
> 2. Update the specification for the cryptographic protection of email
> headers -- both for signatures and encryption -- to improve the
> implementation situation with respect to privacy, security, usability
> and interoperability in cryptographically-protected electronic mail.
> Most current implementations of cryptographically-protected electronic
> mail protect only the body of the message, which leaves significant
> room for attacks against otherwise-protected messages.
>
> 3. The Certificate Management Protocol (CMP) is specified in RFC 4210,
> and it offers a vast range of certificate management options.  CMP is
> currently being used in many different industrial environments, but it
> needs to be tailored to the specific needs of such machine-to-machine
> scenarios and communication among PKI management entities.  The LAMPS
> WG will develop a "lightweight" profile of CMP to more efficiently
> support of these environments and better facilitate interoperable
> implementation, while preserving cryptographic algorithm agility.  In
> addition, necessary updates and clarifications to CMP will be
> specified in a separate document.  This work will be coordinated with
> the LWIG WG.
>
> 4. Provide concrete guidance for implementers of email user agents
> to promote interoperability of end-to-end cryptographic protection
> of email messages.  This may include guidance about the generation,
> interpretation, and handling of protected messages; management of the
> relevant certificates; documentation of how to avoid common failure
> modes; strategies for deployment in a mixed environment; as well as
> test vectors and examples that can be used by implementers and
> interoperability testing.  The resulting robust consensus among email
> user agent implementers is expected to provide more usable and useful
> cryptographic security for email users.
>
> 5. Recent progress in the development of quantum computers pose a threat
> to widely deployed public key algorithms.  As a result, there is a need
> to prepare for a day when cryptosystems such as RSA, Diffie-Hellman,
> ECDSA, ECDH, and EdDSA cannot be depended upon in the PKIX and S/MIME
> protocols.
RS>> (E) In the first sentence, I suggest to change the wording "pose" 
to "may pose" to better reflect the current state (this does not change 
the intent of this work item otherwise). In the second sentence, I 
suggest to change "cryptosystems" to "public key algorithms", so as to 
align with verbiage in 5b below. <<RS
>
> 5.a. NIST has a Post-Quantum Cryptography (PQC) effort to produce one
> or more quantum-resistant public-key cryptographic algorithm standards.
> The LAMPS WG will specify the use of these new PQC public key algorithms
> with the PKIX certificates and the Cryptographic Message Syntax (CMS).
> These specifications will use object identifiers for the new algorithms
> that are assigned by NIST.
>
> 5.b. NIST and other organizations are developing standards for
> post-quantum cryptographic (PQC) algorithms that that will be secure
> even if large-scale quantum computers are ever developed.  However, a
> lengthy transition from today's public key algorithms to PQC public key
> algorithms is expected; time will be needed to gain full confidence in
> the new PQC public key algorithms.
>
> 5.b.i. The LAMPS WG will specify formats, identifiers, and operational
> practices for "hybrid key establishment" that combines the shared
> secret values one or more traditional key-establishment algorithm and
> one or more NIST PQC key-establishment algorithm or a PQC
> key-establishment algorithm vetted by the CFRG.  The shared secret
> values will be combined using HKDF (see RFC 5869) or a key derivation
> function vetted by the CFRG.

RS>> (discussion) In hybrid key establishment scenarios, it is quite 
likely that for a long time one of the parties may be able to compute 
only one of the shared keys used as input to the key derivation 
function, (e.g., k:=kdf(K1, K2), where K1 is ECDH that both devices 
implemen and where K2 is another algorithm [PQC or not]). In this case, 
one should define default drop-in values for K2, so that authenticated 
key agreement does not fail automatically. I am not sure how to exactly 
word this in charter text, but think this is not just an operational 
practice (since changes calculation of values involved in the hybrid 
scheme). While the primary focus should be on PQC, essentially this is 
about crypto agility (PQC or not), where one wants to have the 
cryptographic assurances a nonempty set of algorithms can provide. <<RS

RS>> (discussion) The current text seems to rule out use of, e.g., KMAC. 
Shouldn't one be somewhat more flexible with where one draws kdfs from 
(and doesn't one expect too much of cfrg)? <<RS

>
> 5.b.ii. The LAMPS WG will specify formats, identifiers, and operational
> practices for "dual signature" that combine one or more traditional
> signature algorithm with one or more NIST PQC signature algorithm or
> a PQC algorithm vetted by the CFRG.
> In addition, the LAMPS WG may investigate other updates to documents
> produced by the PKIX and S/MIME WG. The LAMPS WG may produce
> clarifications where needed, but the LAMPS WG shall not adopt
> anything beyond clarifications without rechartering.

RS>> During IETF-110, it was suggested to issue a potential call for 
adoption for various drafts, where, e.g., 
https://datatracker.ietf.org/doc/draft-struik-lamps-verification-friendly-ecdsa/ 
is hard to categorize as a clarification. Shouldn't we add another work 
item, so as to make sure this can be tackled? Or, should we simply scrap 
all but the first sentence of this paragraph (where the preamble of the 
recharter text already suggests a sufficiently high bar for taking this 
on, since it states "where there is a known constituency interested in 
real deployment and there is at least one sufficiently well specified 
approach to the update so that the working group can sensibly evaluate 
whether to adopt a proposal". <<RS


>
> MILESTONES
>
> Task 1:
> Jul 2021 Adopt a draft for short-lived certificate conventions
> Mar 2022 Short-lived certificate conventions sent to IESG for BCP 
> publication
>
> Task 2:
> DONE Adopt a draft for header protection conventions
> Nov 2021 Header protection conventions sent to IESG for standards 
> track publication
>
> Task 3:
> DONE Adopt a draft for CMP updates
> DONE Adopt a draft for CMP algorithm
> DONE Adopt a draft for Lightweight CMP profile
> Dec 2021 CMP updates sent to IESG for standards track publication
> Dec 2021 CMP algorithms sent to IESG for standards track publication
> Dec 2021 Lightweight CMP profile sent to IESG for informational 
> publication
>
> Task 4:
> May 2021    Adopt a draft for end-to-end email user agent guidance
> Jul 2022    End-to-end email user agent guidance sent to IESG for 
> informational publication
>
> Task 5.a:
> Aug 2021    Adopt draft for PQC KEM public keys in PKIX certificates
> Aug 2021    Adopt draft for PQC KEM algorithms in CMS
> Sep 2021    Adopt draft for PQC signatures in PKIX certificates
> Sep 2021    Adopt draft for PQC signatures in CMS
>
> Task 5.b.i:
> Sep 2021    Adopt draft for public keys for hybrid key establishment 
> in PKIX certificates
> Sep 2021    Adopt draft for hybrid key establishment in CMS
>
> Task 5.b.ii:
> Sep 2021    Adopt draft for dual signatures in PKIX certificates
> Sep 2021    Adopt draft for dual signature in CMS
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867