Re: [lamps] [EXTERNAL] Re: I-D Action: draft-ietf-lamps-pq-composite-kem-00.txt

[Mike Ounsworth <[e-mail]>]

Hey Ilari,



> I don't think it is "implementation bugs" that are the main gating

factor in trusting post-quantum algorithms, but rather the actual

strength of those algorithms.

This is a religious debate to which there are many opinions and no correct answer, therefore, in my opinion, completely pointless to debate.
There is a non-zero risk of catastrophic algorithmic attacks.
There is also non-zero risk of implementation bugs leading to CVEs about weak encryption entropy or oracle attacks or whatever.
That’s it, debate over, right? Debating which one is the “main” risk seems pointless to me.


As to all your other comments; I appreciate your review, but it’s a bit premature. This is just a renaming to indicate that it’s adopted, we have not yet tackled any of the editorial work. See the long list of TODOs on slide 4 of my 117 LAMPS presentation [1]. Feel free to open github issues if you think there are things not already covered by that list. Or feel free to do some editing and submit a PR.


[1]: https://datatracker.ietf.org/meeting/117/materials/slides-117-lamps-composites-00.pdf

---
Mike Ounsworth

From: Spasm <[e-mail]> On Behalf Of Ilari Liusvaara
Sent: Wednesday, August 23, 2023 12:25 PM
To: [e-mail]
Subject: [EXTERNAL] Re: [lamps] I-D Action: draft-ietf-lamps-pq-composite-kem-00.txt

On Wed, Aug 23, 2023 at 07: 59: 59AM -0700, internet-drafts@ ietf. org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the Limited Additional > Mechanisms


On Wed, Aug 23, 2023 at 07:59:59AM -0700, [e-mail]<mailto:[e-mail]> wrote:

>

> A New Internet-Draft is available from the on-line Internet-Drafts

> directories. This Internet-Draft is a work item of the Limited Additional

> Mechanisms for PKIX and SMIME (LAMPS) WG of the IETF.

>

>    Title           : Composite KEM For Use In Internet PKI

>    Authors         : Mike Ounsworth

>                      John Gray

>    Filename        : draft-ietf-lamps-pq-composite-kem-00.txt

>    Pages           : 25

>    Date            : 2023-08-23



Reading the draft for a quick review:





- Section 2. Introduction:



I don't think it is "implementation bugs" that are the main gating

factor in trusting post-quantum algorithms, but rather the actual

strength of those algorithms.



And I don't think the question on what algorithms one should migrate

to is so unclear anymore. The NISTPQC process has yielded a lot of

information on that, even ignoring the final selection.





- Section 3.2. kema-CompositeKEM:



"PARAMS TYPE CompositeKemParams ARE required"



Uh, what does that mean? That algorithms are parametrized?





- Section 3.5. CompositKemParameters:



This looks to me to be for supporting generic composition, which I

thought was ripped out.





"Implementation SHOULD NOT rely directly on the algorithmIDs contained

in the CompositeKemParams and SHOULD verify that they match the

algorithms expected from the overall composite AlgorithmIdentifier."



... That sounds like a rake factory. :-)





- Section 3.6. Encoding Rules:



"EDNOTE: will this definition include an ASN.1 tag and length byte

inside the OCTET STRING object? If so, that's probably an extra

unnecessary layer."



I think that including those would mess up protocol alignment, so the

tags and lengths should not be included.





- Section 3.7. KEM Combiner:



"TODO: as per https://urldefense.com/v3/__https://www.enisa.europa.eu/publications/post-quantum-cryptography-integration-study__;!!FJ-Y8qCqXTj2!fCIie1Y_7nyWRuMLCmqy2UjpCcyscCqVkOJo6QHQO9z0PUFI38yr61Bsb43w89_TFmDZGh1CeDKNU-UMZKB5jIjhM7NKLJtb6AA$<https://urldefense.com/v3/__https:/www.enisa.europa.eu/publications/post-quantum-cryptography-integration-study__;!!FJ-Y8qCqXTj2!fCIie1Y_7nyWRuMLCmqy2UjpCcyscCqVkOJo6QHQO9z0PUFI38yr61Bsb43w89_TFmDZGh1CeDKNU-UMZKB5jIjhM7NKLJtb6AA$>

section 4.2, might need to specify behaviour in light of KEMs with a

non-zero failure probility."



Since the KEMs are IND-CCA2, the failure probability is negligible.





And uh, no SHA3-512 please.



Furthermore, to align with Kyber, one should only use KMAC256, SHAKE256

or cSHAKE256.





"K: the ASCI value of the name of the Kem Type OID."



I presume that "ASCI" should be "ASCII" and "Kem" should be "KEM".





- Section 4. Algorithm Identifiers



"EDNOTE: I believe that [SP.800-56Ar3] and [BSI-ECC] give equivalent

and interoperable algorithms, so maybe this is extranuous detail to

include?"



Actually, the algorithms are not interoperable in general case.

Specifically, if h > 1, the results will differ. However, with

all the curves considered here, h=1, in which case the algorithms

are compatible.





- Section 4.1. Notes on id-Kyber768-RSA-KMAC256:



"For use with id-Kyber768-RSA-KMAC256, the keyDerivationFunction SHALL

be id-sha3-384 and keyLength SHALL be 384."



Maybe SHAKE256 with 384 bit output instead (alignment with Kyber)?





"EDNOTE: Since the crypto is fixed, we could omit the parameters

entirely and expect implementations to re-constitute the params

structures as necessary in order to call into lower-level crypto

libraries."



>From what I can tell, the parameters do not enter cryptographic

computations, so there is no need to re-constitute the parameters.



So just fixing the thing would simplify it a lot.





- Section 7.1. Policy for Deprecated and Acceptable Algorithms:



One subtle point is that in asymmetric encryption, the way hashes are

used is much more resilient compared to use in signatures.



So even quite broken hash functions are not that alarming, but not good

for other reasons.





- Section  7.2. OR Modes:



I don't think OR modes make any sense with the present framework.









-Ilari



_______________________________________________

Spasm mailing list

[e-mail]<mailto:[e-mail]>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!fCIie1Y_7nyWRuMLCmqy2UjpCcyscCqVkOJo6QHQO9z0PUFI38yr61Bsb43w89_TFmDZGh1CeDKNU-UMZKB5jIjhM7NKgjdFIT4$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!fCIie1Y_7nyWRuMLCmqy2UjpCcyscCqVkOJo6QHQO9z0PUFI38yr61Bsb43w89_TFmDZGh1CeDKNU-UMZKB5jIjhM7NKgjdFIT4$>

Any email and files/attachments transmitted with it 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.