Re: [lamps] I-D Action: draft-ietf-lamps-dilithium-certificates-03.txt

[Bas Westerbaan <[e-mail]>]

> On 29 Feb 2024, at 11:51, Kampanakis, Panos <[e-mail]> wrote:
> 
> Thanks John.
>  
> We are tracking your suggestions in git issuehttps://github.com/lamps-wg/dilithium-certificates/issues/12 We will fix them in the next iteration.
>  
> Regarding SLH-DSA in X.509, https://datatracker.ietf.org/doc/draft-gazdag-x509-slhdsa/ was recently spun off from draft-gazdag-x509-hash-sigs, so it should cover it. 
>  
> +1 about PQ HPKE vs ECIES. We had written a paper exploring it inhttps://ia.cr/2022/414 and Bas has https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/ which combines x25519 with Kyber768. I think it is based on X-Wing. Personally, I would stir the Kyber768 ciphertext in the KDF in order to have a more straightforward path to CCA2 security, but regardless, it is PQ HPKE. 

The draft you linked predates X-Wing and does mix in the Kyber ciphertext (but uses round 3 Kyber.)

Best,

 Bas


>  
>  
>  
> From: Spasm <[e-mail] <mailto:[e-mail]>> On Behalf Of John Mattsson
> Sent: Wednesday, February 28, 2024 5:02 PM
> To: [e-mail] <mailto:[e-mail]>
> Subject: RE: [EXTERNAL] [lamps] I-D Action: draft-ietf-lamps-dilithium-certificates-03.txt
>  
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
>  
> Review of draft-ietf-lamps-dilithium-certificates-03
>  
> Hi,
>  
> I am very supportive of this work. I hope it will be published soon after FIPS 204 (ML-DSA) is published. Let me know if I can help. Ericsson plans to make sure that 5G introduces ML-DSA and ML-KEM everywhere public key cryptography is used. 5G uses IETF protocols for almost all public key cryptography, the exception is IMSI encryption, which uses ECIES specified by SECG. Quantum-resistant IMSI encryption will likely use HPKE.
>  
> - I would very much like to see a similar draft as this for SLH-DSA published shortly after NIST published FIPS 205.
>  
> - In addition to Certificates and CRLs, 5G uses the following RFC 2986, 4210, 6090.
> Can we make sure that this document works with RFC 2986, 4210, and 6960 as well? Maybe it already does, then it should be good to mention that.
>  
> - Would be good if the document started referring to Draft FIPS 204, so that the final update is just a reference update. Right now thing like the names ML-DSA-44, ML-DSA-65, ML-DSA-87, and "security categories 2, 3 and 5" do not have any reference to NIST.
>  
> - "It describes the encoding of digital signatures and public keys generated with quantum-resistant signature algorithm ML-DSA."
>  
> The keys are not generated with ML-DSA maybe "encoding of public keys and digital signatures generated with"
>  
> - "copmatible" -> "compatible"
>  
> - “The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded tbsCertificate [RFC5280 <https://www.ietf.org/archive/id/draft-ietf-lamps-dilithium-certificates-03.html#RFC5280>].”
>  
> This is only true for certificates. In certificate lists it is calculated over tbsCertList.
>  
> -“The public parameters for ML-DSA are based upon a polynomial ring R_q for prime q. A (k*l) public matrix A is produced, consisting of polynomials whose coefficients are sampled uniformly at random from the integers modulo q. This sampling is performed by expanding a nonce (rho) using an XOF.”
>  
> I think this could be removed. This document can just refer to FIPS 204.
>  
> - “k+l)*ceiling(log(2*eta+1))+13*k]”
> |=======+=======+=====+========+========+========|
> | Level | (k,l) | eta |  Sig.  | Public | Private|
> |       |       |     |  (B)   | Key(B) | Key(B) |
> |=======+=======+=====+========+========+========|
> |   2   | (4,4) |  2  |  2420  |  1312  |  2528  |
> |   3   | (6,5) |  4  |  3293  |  1952  |  4000  |
> |   5   | (8,7) |  2  |  4595  |  2592  |  4864  |
> |=======+=======+=====+========+========+========|
>  
> I think it is preferable to remove the formula and eta. People are not expected to make their own ML-DSA variants. I think the information in the table should be only:
>  
> ML-DSA-44 |   2   |  2420  |  1312  |  2528  |
> ML-DSA-65 |   3   |  3293  |  1952  |  4000  |
> ML-DSA-87 |   5   |  4595  |  2592  |  4864  |
>  
> - “modeled under existentially unforgeable digital signatures with respect to an adaptive chosen message attack (EUF-CMA).”
>  
> ML-DSA is designed to be strongly existentially unforgeable under chosen message attack (SUF-CMA) i.e., it is expected that even if an adversary can get the honest party to sign arbitrary messages, the adversary cannot create any additional valid signatures based on the signer’s public key, including on messages for which the signer has already provided a signature). This property is not provided by classical signature schemes such as ECDSA
>  
> Cheers,
> John Preuß Mattsson