Re: [lamps] LAMPS Re-charter

[Rene Struik <[e-mail]>]

Brief further discussion below...

On 2021-03-22 12:17 p.m., Russ Housley wrote:
> Rene:
>
> Comments below.  I dropped the milestone proposals since you did not 
> comment on them.
>
>> 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
>
> These make sense to me.  Symmetric ciphers and hash functions are not 
> concerns here.
>
>>>
>>> 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
>>
> I do not agree with this characterization.  If one of the parties 
> cannot use the PQC key-establishment algorithm, then they are not 
> using a hybrid.  In this case, the party that is capable of using 
> the PQC key-establishment algorithm will have to settle for a 
> traditional only mechanism, or refuse the connection.
>
> During the LAMPS WG interim session, Max Pala talked about the 
> possibility of certificates that contained public keys for traditional 
> and PQC algorithms.  Since that 
> session, draft-ounsworth-pq-composite-sigs has been revised to capture 
> some suggestions for signature algorithms.  Something like this will 
> be needed for key-establishment algorithms as well.

RS>> I do not see the issue. Conceptually, hybrid is simply L schemes at 
the same time, where L=1 correspond to (what you call) traditional case. 
No matter how one calls this, the problem of having to cater to very 
long transition time windows remains. As far as I can tell, the informal 
description I used above is consistent with that in Section 2 of NIST SP 
800-56C - Recommendation for Key-Derivation Methods in Key-Establishment 
Schemes, Rev2 (August 18, 2020), which states (second para):

    In addition to the currently approved techniques for the generation
    of the shared secret Z as specified in SP 800-56A and SP 800-56B,
    this Recommendation permits the use of a “hybrid” shared secret of
    the form Z′ = Z || T, a concatenation consisting of a “standard”
    shared secret Z that was generated during the execution of a
    key-establishment scheme (as currently specified in [SP 800-56A] or
    [SP 800-56B]) followed by an auxiliary shared secret T that has been
    generated using some other method. The content, format, length, and
    method used to generate T must be known and agreed upon by all
    parties that will rely upon the derived keying material, as well as
    by any agents trusted to act on their behalf. The key-derivation
    methods specified in this Recommendation will process a hybrid Z′ in
    the same way they process a standard Z. Therefore, for simplicity of
    notation and exposition, any shared secret denoted by the symbol Z
    in the remainder of this Recommendation can be of either the
    “standard” or “hybrid” variety.

The advantage of this "fits both world" model is that an implementation 
that already accommodates the traditional key establishment scheme can 
simply reuse the surrounding functionality, while only requiring a 
"swap-in" of the key establishment and shared key computation flows, 
once the policy would dictate so. Having a data object T already in 
place (which for traditional devices could, e.g., be set to a fixed 
string) would facilitate a change, where T is set to the computed 
outcome whatever alternative key establishment model one wants to enable 
as well. {This assumes one can reuse the message flows.}

<<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
>>
> The LAMPS WG does not have many cryptographers in the group.  We do 
> have a few, but not as many as CFRG, so we need to depend on the CFRG 
> to get as many cryptographers involved as possible.
>
>>>
>>> 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
>>
> Three options for a way forward were suggested.  I think the 
> discussion of the options needs to continue.  Once a way forward is 
> agreed, then we can recharter again if needed.
RS>> I would rather not having administrative hurdles be in place if 
those can be avoided (these take lots of time and also unnecessarily 
delay actual deployment). Since the suggested cause of action path of 
IETF-110 already includes potential adoption, it should not be left as 
ambiguous as to whether adopted material is chartered territory or not. 
I could try and come up with some suggested text for this (although am 
not a parliamentarian). <<RS
>
> This part is unchanged from the current charter, and there was a fair 
> amount of discussion about it previously.  I'd reather not reopen that 
> discussion.
>
> Russ
>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]