Re: [lamps] [EXTERNAL] Re: LAMPS Re-charter

[Mike Ounsworth <[e-mail]>]

Hi Russ and Rene,

I’ll wade into this. 

My current understanding is that strong cryptography wants hybrid and dual modes to be a “MUST USE ALL” sort of thing, while strong backwards compatibility wants a “client can use as many as they support” kind of thing. Conflicting requirements. For signatures you can design such a system where the signer produces all the signatures and the verifying only checks as many as they can since dual signatures are parallel and independent anyway (In an upcoming version of draft-ounsworth-pq-composite-sigs I have added a separate OID for "Composite-OR" to keep the wishy-washy dual signatures distinct from the strict ones, and I'm expecting a healthy debate to arise about whether this is a good idea or not).

But for keyEncipherment and dataEncipherment I don't think you can do that at all; either you do something like:

RSA_encrypt(Z)
PQ_encrypt(T)
K = kdf( Z || T )
or
Z = ECDHE_agree()
PQ_encaps(T)
K = kdf( Z || T )

which requires the client to have implementations of both RSA / ECDHE and PQ.

Or, you do:

RSA_encrypt(Z)
PQ_encrypt(Z)
K = kdf( Z )
or
Z = ECDHE_agree()
PQ_encaps(Z)
K = kdf( Z )
(which may lead to some weird protocol gymnastics..)

Which allows the client to succeed even if it does not understand PQ, but is in fact not a hybrid mode, so, actually, don't do this. So I don't think it's possible to produce hybrid keyEncipherment or dataEncipherment payloads that can be read by both upgraded and legacy clients.

That said, I think I agree with Rene that there will be scenarios where a sender is trying to encrypt for or establish a shared secret with a recipient who has a Composite public key with a PQ alg that the sender does not have an implementation of (ie sender understands composite, but not that PQ alg). I think it is in-scope for any RFCs we produce on this topic to give guidance here: we could give NOT RECOMMENDED type guidance (ie senders should not even attempt to send data unless they support all of the recipient's pub keys), or we could explicitly allow it in either a traditional structure or in a {RSA, null} composite structure. Thoughts? Either way, I think that's an edge-case of implementing hybrid and does not need to be called out in the charter.

To make this more complicated, in many cases the right answer might be that if the recipient wants clients to have the option of communicating with them on RSA-only, then they should publish an RSA-only certificate along with their {RSA, PQ} composite certificate, but I'm not sure that makes sense in all contexts. I'm not sure if we're planning to continue developing the multiple certificates model that Russ was advocating for at the Jan 28 interim meeting, but it handles this situation even less gracefully since there is no good way in a non-negotiated protocol for a recipient to specify whether it wants to receive RSA-only communications.

Related to this: draft-ounsworth-pq-composite-sigs currently defines all the composite structures as "SEQUENCE (1..MAX) OF ..". In an upcoming version I'm planning to change that to "(2..MAX)" unless anyone has a strong need to produce a composite key, signature, or ciphertext with a single element in it?

---
Mike Ounsworth

From: Spasm <[e-mail]> On Behalf Of Russ Housley
Sent: March 22, 2021 1:22 PM
To: Rene Struik <[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] LAMPS Re-charter

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________________
Rene:

Comments below.


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
To me, hybrid key-establishment algorithm MUST combine the output of at least one traditional algorithm AND at least one PQC algorithm.  Otherwise, you are just using the traditional  key-establishment algorithm OR the PQC algorithm.
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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-struik-lamps-verification-friendly-ecdsa/__;!!FJ-Y8qCqXTj2!P5P484zgCE-i_SjUZ-vexzoUuiqLYC-niGU4bL9gpVuF7rddsO7NbgmWQAQpPHCj3s4WyN6-oQ$ 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

Depending on the outcome of the discussion, a charter update may not be needed.

Russ