Re: [lamps] Call for adoption for the composite-related Internet-Drafts

[Mike Ounsworth <[e-mail]>]

The call for adoption period ends tomorrow. I do not envy Russ and Tim needing to make a consensus call on this.


So my last appeal is procedural: this is explicitly in-charter (5.b.i and 5.b.ii), there are clearly people who want it, and we are clearly going to continue spending effort on it, so why not make that official?



I expect I'm not the only one re-reading RFC 7221 to see what WG Adoption is really meant to be.

I note:

*       "Equally, adoption by a working group does not guarantee publication of the document as an RFC."

*       "Absent explicit agreement, adopting a document does not

      automatically mean that the working group has agreed to all of its

      content.  So a working group (or its charter) might explicitly

      dictate the basis for retaining, removing, or modifying some or

      all of a draft's content, technical details, or the like.



That means we're not voting on whether these documents should be published, or even whether they contain the right solution; we're voting on whether the WG wants to continue the discussion around these documents with the goal of making meaningful progress towards WG Charter items 5.b.i & 5.b.ii and the following WG milestones:


Dec 2021
Adopt draft for dual signature in CMS
Dec 2021
Adopt draft for dual signatures in PKIX certificates
Dec 2021
Adopt draft for hybrid key establishment in CMS
Dec 2021
Adopt draft for public keys for hybrid key establishment in PKIX certificates

---
Mike Ounsworth

From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
Sent: Tuesday, June 13, 2023 5:43 PM
To: Tim Hollebeek <tim.hollebeek=[e-mail]>; Russ Housley <[e-mail]>; LAMPS <[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Call for adoption for the composite-related Internet-Drafts

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Thank you Tim. I really really appreciate this response, both for the technical guidance on what these drafts should be, and the "chair hat" leadership that it provides.

We should find some time offline to discuss how you imagine these drafts could be split up. For example, what would a minimum-viable and self-contained composite-kems draft look like? I assume there is some minimal set of things we would need to lift over from the composite-keys drafts.

I totally see your point that these drafts are trying to boil the ocean. That string of MAYs in composite-sigs 3.1 is well-called-out. That paragraph is the way it is because over the years people have said:

  *   We want composite keys to be bound all the way down to the keystore.
  *   We want the EC key to come from a FIPS mode hardware module and the PQ to come from *somewhere else*.
  *   We don't want to modify *insert protocol here* to carry two signatures, so could we have two unrelated certificates create a single CompositeSignature - I've even heard it suggested that for cases that already have defined semantics for multiple CMS SignerInfos, you could have a single composite SignerInfo with two Certificates - this avoids the failure mode where the client accepts the RSA signature and doesn't look further to realize that there is also a PQ signature that it would actually have been capable of processing.
Each of those seems it probably has motivating use-cases, so as you say, that leads to a document that tried to do everything and that's completely devoid of meaningful usage guidance because every weird permutation shows up in some use-case somewhere.




> Composite doesn't really offer any other transition benefits I can see, and honestly, was more attractive several years ago before we had as much confidence in PQC algorithms as we have now.

I'd like to offer this benefit; the FIPS certification queue is years long (and has gotten longer since FIPS 140-3). SP 800-208 (XMSS, LMS) was published in 2020 and we still can't can't even start a FIPS certification because there are no CAVP test vectors yet. If we get final NIST PQC specs in 2024, then the first FIPS certification for a PQC HSM will be issued in ... what? ... 2027?

That's where composites come in: as per the NIST PQC FAQ and SP 800-56Cr2, if you have a FIPS certified ECDSA P-256, then you also have a FIPS certified Dilithium3-ECDSA-P256. If you have a FIPS certified ECDH P-256, then you also have a FIPS certified Kyber512-ECDH-P256. Also, while we haven't made much noise about this, if you have a FIPS certified ECDSA, then you also have FIPS-certified GOST-ECDSA and SM2-ECSDA. This is as much about compliance and being able to claim "FIPS mode" for things that are not yet or not ever FIPS approved algorithms.

I'm going to posit that there is literally no way to meet CNSA's aggressive timelines without either CNSA relaxing requirements for FIPS certifications, or applying hybrids.

---
Mike Ounsworth

From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Tim Hollebeek
Sent: Tuesday, June 13, 2023 2:57 PM
To: Russ Housley <[e-mail]<mailto:[e-mail]>>; LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [lamps] Call for adoption for the composite-related Internet-Drafts

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
I have some rather complicated feelings about these drafts, which is going to be a bit of a challenge to explain.  But I'm going to try.  I think at the end of the day, where I come down is that there really is an important problem to be solved here, but I'm not sure if these drafts have reached the necessary clarity in scope and maturity to be adopted.  I think there's a couple good concrete drafts struggling to get out of these drafts, but they're not there yet.

And to be clear, the problem that I think is important is that falling back to RSA ciphertext instead of plaintext is attractive in some use cases, although it will be increasingly less so with time, as RSA's security value eventually approaches zero.  But we have a significant amount of time before that happens.  Composite doesn't really offer any other transition benefits I can see, and honestly, was more attractive several years ago before we had as much confidence in PQC algorithms as we have now.  But still, I think the idea is attractive, and people will do it, so I think it's important to have guidance about how to do it securely.  And there are a lot of good technical details about that in these drafts.  At the very least, these standards allow people to agree on the various design decisions that need to be made, which enables interoperability.

I actually personally think that, in general, people often have too high a bar for adoption.  But I think that one of the most critical elements for an adoption call is that there is WG consensus on the problem to be solved, and the scope, and several parts of these drafts read like "well, you can maybe do this, or maybe that, but you need to worry about this other thing over there ..."  There are far more MAYs and SHOULDs in these drafts than concrete, explicit specifications about exactly how the technology works and MUST be used.  And this is critical because the drafts themselves actually do a pretty good job calling out some of the serious challenges that need to be overcome to get this technology to work in the real world.  For example, the need to look inside a composite key in order to determine whether the underlying RSA key is reused elsewhere or compromised.  That deserves some explicit consideration and requirements, not just a suggestion that something SHOULD be done about it by implementors, without any concrete guidance.  Another example is the long list of MAYs in section 3.1 of the pq-composite-sigs draft.

As to whether all of this causes PKIX-induced flashbacks or whether it properly complies with the spirit of the "L" in LAMPS ... charters have words and text, not spirits, and I think the chairs and area directors have actually done a pretty good job following the working group consensus as we navigate some pretty challenging issues during preparations for the upcoming post-quantum transition.  As to whether certain individuals are or are not happy with this, I would remind people that here at IETF, we reject kings.  As chairs, we are called to evaluate and follow working group consensus, not the desires of certain individuals who may have historically had certain views when they were in charge.  Having had several long conversations with many of the people involved, I think I can safely say that long conversations about what may or may not have gone horribly wrong with the PKIX working group is not horribly relevant or helpful in solving the problems we are trying to solve today.

Key encapsulation is actually far simpler and less dangerous than signatures, and explicit, standardized design choices about how to do it are useful.  The composite-kem draft is actually significantly more mature and well-scoped than the other two.  It has a dependency on pq-composite-keys, though, which still has a lot of extraneous and unnecessary stuff that I personally would like to see removed.  Getting an good, agreed upon scope for those two and pushing them forward might be a good next step.

Signatures are very complicated, and I actually thank the authors for some very insightful discussions that have helped me understand exactly how tough of a problem they are, and the many challenges of figuring out how they can work with composite keys.  It's possible composite should just be for KEMs, as the draft shows that attempting to do composite signing gets complicated fast.  But as I noted above, there are benefits to composite signatures as well.  I feel like we're not quite to the end of the "design funnel" yet, and there still need to be some serious conversations about exactly what we are trying to achieve, and exactly how it is supposed to work.  Treating signing of certificates, and signing of documents, and signing of code as the same thing feels like a mistake to me.  I think when you get down to how actual signatures work, it actually matters whether you are trying to set up a hierarchy of composite certificates or trying to do a composite legal signature on a document, as the security considerations are very different.  I think I have convinced myself that trying to handle that under a single document that just says "this is how PQ composite signatures work, generically" ... is probably not going to work.  But I could be wrong about that last point.

So I unfortunately think I'm a "no" at this point, though I really do hope that a lot of the great work and details in these documents eventually finds a home, either in later versions that do get adopted, or elsewhere.  There's some really good stuff in here.

-Tim


From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Russ Housley
Sent: Tuesday, May 30, 2023 3:43 PM
To: LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: [lamps] Call for adoption for the composite-related Internet-Drafts

Should the LAMPS WG adopt these three Internet-Drafts ...

1) "Composite Signatures For Use In Internet PKI" in draft-ounsworth-pq-composite-sigs-09?

2) "Composite Public and Private Keys For Use In Internet PKI" in draft-ounsworth-pq-composite-keys-05?

3) "Composite KEM For Use In Internet PKI" in draft-ounsworth-pq-composite-kem-02?

This document was discussed in the LAMPS session at several IETF meetings.  The authors sent a note saying that they incorporated the feedback that they received at IETF 116.

Please reply to this message by Wednesday, 14 June 2023 to voice your agreement or disagreement with adoption by the LAMPS WG.

On behalf of the LAMPS WG Chairs,
Russ

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.