[lamps] Re: Independent Crypto Review - Re: WG Last Call for draft-ietf-lamps-rfc4210bis and draft-ietf-lamps-rfc6712bis

[Thom Wiggers <[e-mail]>]

Hi all,

I think that the main thing that remains between my comments and Hendrik’s answers is up to the authors and the working group to decide whether anything warrants (editorial) changes. If you’re all happy, I’m happy :-)

Cheers,

Thom

> Op 12 jul 2024, om 16:49 heeft Brockhaus, Hendrik <[e-mail]> het volgende geschreven:
> 
> Thom
>  
> Thank you for your sniff-test of our specification regarding KEM-support for POP and message protection.
> See my feedback below. @Mike Ounsworth <mailto:[e-mail]>, do you want to add something?
> I added the LAMPS email list to make others aware of the discussion.
>  
> Hendrik
>  
> Von: Thom Wiggers <[e-mail] <mailto:[e-mail]>>
> Gesendet: Mittwoch, 10. Juli 2024 11:39
> An: Brockhaus, Hendrik (T CST SEA-DE) <[e-mail] <mailto:[e-mail]>>
> Cc: Mike Ounsworth <[e-mail] <mailto:[e-mail]>>; Russ Housley <[e-mail] <mailto:[e-mail]>>
> Betreff: Re: Independent Crypto Review - Re: WG Last Call for draft-ietf-lamps-rfc4210bis and draft-ietf-lamps-rfc6712bis
>  
> Hi Hendrik, Russ, and Mike,
>  
> The following is my (time-limited) review of the draft, in which I focused on the KEM-based message protection and proof-of-possession mechanisms. The following should be considered a “sniff-test”, not a comprehensive cryptographic review as that would require considerably more time than I have available. 
>  
> Overall, my main points are questions of clarification.
>  
> On message protection:
>  
> - In the KemBMParameters structure, does the AlgorithmIdentifier structure for the kdf parameter carry the required salt and/or other labels necessary to derive the same shared secret? (Seems weird that those parameters would be part of an AlgorithmIdentifier, but that might just be convention that I’m less familiar with). I did note that the running text does say that ‘kdf’ should contain any necessary parameters.
> [HB] If kdf parameter are required they are given in the parameters component of the AlgorithmIdentifier, e.g., RFC 8018 for PBKDF2. For HKDF the parameters component is left empty, see RFC 8619, accommodating operation without salt.
> - I noticed that the key for the MAC is derived using optional, algorithm-specific KemContext information. I’m assuming that this information is present in part to prevent re-encapsulation attacks for algorithms that are not ciphertext-binding [https://eprint.iacr.org/2023/1933] (I have not evaluated if this protocol can be vulnerable to such attacks—but eliminating them can’t hurt). If this is an implicit design requirement/desirable property, this might be worth including in the security considerations? Mike probably has more informed ideas about this.
> [HB] We followed the discussion on cms-kemri if the public key or the ct shall be used as additional input to the kdf. As ML-KEM (Kyber) already uses the ct with an internal kdf it was decided not to add it again in the cms-kemri but leave it to the algorithm profiling for CMS to require it or not. The authors of rfc4210bis have followed this path. If people think adding ct as standard input to the kdf to be on the safe side, it can be considered. If there is anything else to add to the input of the kdf, e.g., the AlgorithmIdentifier of the MAC, please speak up.
> - My main question is: what is the message input to the MAC? I could not easily find this in the document, and the input to the MAC is relevant to the ability of shared key ssk being re-used for further PKI transactions (i.e. inputs likely must not collide).
> [HB] The message input to the MAC is the sequence of PKIHeader and the PKIBody as specified in Section 5.1.3.
> - With the large caveat that my review was limited in time and I did not properly model any details, the key agreement scheme in this section seems to pass the sniff test: Alice and Bob will have a shared secret after executing this that should only be known to them.
>  
> On proof of possession:
>  
> - The generic mechanisms of both indirect and direct challenges seem to pass the sniff test, with some caveat on the direct challenges described below.
> - I am having a hard time figuring out how the shared secret between EE and RA/CA is computed; there should presumably be some KDF involved like in message protection. Am I just missing where this is specified? 
> [HB] The RA/CA provides the encrypted Rand (a random integer together with the sender’s name) in an EnvelopedData structure. If cms-kemri is used, this also involves a kdf. The integer is returned in clear by the EE.
> - The same comments regarding (implicitly) avoiding KEM re-encapsulation attacks apply here. Again, I’m not sure if these attacks are theoretically applicable and/or actually a problem, but seem worth briefly looking into (if only to ease any modeling).
> [HB] We use standards CMS EnvelopedData incl. cms-kemri as is.
> - Regarding security consideration 8.2, have you considered returning H(rand) instead of rand to further avoid these decryption oracles? However, arguably the derivation of challenge encryption key should be set up in a way to sufficiently domain-separate this. Again, this comes back to how the challenge encryption keys are set up.
> [HB] If no signature-based POP is possible the preferred method in CMP is the indirect method. Therefore, the direct method is a sideline. When updating the text on the direct POP method we intended to change as little as possible to the current text and only introduced EnvelopedData instead of the challenge filed containing the plain encrypted Rand as OCTET STRING. If people think, we should return hash of Rand instead of the plain integer, this can be considered of course..
>  
> I hope this feedback is helpful.
>  
> Cheers,
>  
> Thom Wiggers
>  
> Op 9 jul 2024, om 13:55 heeft Brockhaus, Hendrik <[e-mail] <mailto:[e-mail]>> het volgende geschreven:
>  
> Thom
>  
> I know that you already did a review the KEM-support for message protection a year ago.
> May I ask you again to provide a crypto review of the support of managing KEM-certificates, as the document is now complete and the WG would like to get some external feedback.
>  
> BTW, I submitted a version 12 yesterday. The current links for my email below are the following:
> Message protection: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-12#section-5.1.3.4
> POP: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-12#section-4.3.4
> Github repro: https://github.com/lamps-wg/cmp-updates
>  
> Many thanks in advance,
> Hendrik
>  
> Von: Brockhaus, Hendrik <hendrik.brockhaus=[e-mail] <mailto:hendrik.brockhaus=[e-mail]>>
> Gesendet: Donnerstag, 20. Juni 2024 07:58
> An: Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]>>; Russ Housley <[e-mail] <mailto:[e-mail]>>; LAMPS <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Tomas Gustavsson <[e-mail] <mailto:[e-mail]>>; David Hook <[e-mail] <mailto:[e-mail]>>; Sean Turner <[e-mail] <mailto:[e-mail]>>
> Betreff: [lamps] Re: [EXTERNAL] Re: WG Last Call for draft-ietf-lamps-rfc4210bis and draft-ietf-lamps-rfc6712bis
>  
> Russ, Mike
>  
> Thank you for requesting this review. I would also feel much better to have another review of the KEM-support.
> The KEM support for message protection is specified in https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-11#section-5.1.3.4. In short, the approach derives a symmetric key for MAC-based message protection from an authentic KEM shared secret.
> The KEM support for POP utilizes existing mechanisms, see https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc4210bis-11#section-4.3.4.
>  
> @Sean Turner <mailto:[e-mail]> You mentioned during last IETF, that you are considering adding KEM support in you CMC Update. Could you have a look on the approach we took in CMP and provide a review?
>  
> Hendrik
>  
>  
> Von: Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]>>
> Gesendet: Mittwoch, 19. Juni 2024 21:18
> An: Russ Housley <[e-mail] <mailto:[e-mail]>>; LAMPS <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Tomas Gustavsson <[e-mail] <mailto:[e-mail]>>; David Hook <[e-mail] <mailto:[e-mail]>>
> Betreff: [lamps] Re: [EXTERNAL] Re: WG Last Call for draft-ietf-lamps-rfc4210bis and draft-ietf-lamps-rfc6712bis
>  
> Russ, I agree. I am uncomfortable with this passing WGLC until it receives independent crypto review.
>  
> I’m gonna start poking people.
>  
> @[e-mail] <mailto:[e-mail]>
> You promised me that Nokia would provide a cryptographic review of how we are supporting KEMs in CMP. I’m calling in any favours that you owe me! 😝
>  
> Also @Tomas Gustavsson <mailto:[e-mail]> and @David Hook <mailto:[e-mail]> are people with CMP implementations who could provide review.
>  
> ---
> Mike Ounsworth
>  
> From: Russ Housley <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, June 19, 2024 2:14 PM
> To: LAMPS <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] [lamps] Re: WG Last Call for draft-ietf-lamps-rfc4210bis and draft-ietf-lamps-rfc6712bis
> Importance: High
>  
> I have only seen comments from me so far. On one hand, the vast bulk of the changes are from the already approved -updates documents. On the other hand, rfc4210bis adds support for certificates that contain KEM public keys. Please review! Russ
>  
> I have only seen comments from me so far.  On one hand, the vast bulk of the changes are from the already approved -updates documents.  On the other hand, rfc4210bis adds support for certificates that contain KEM public keys.  Please review!
>  
> Russ
>  
>  
> > On Jun 5, 2024, at 11:50 AM, Russ Housley <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Title: Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
> > Authors: H. Brockhaus, D. von Oheimb, M. Ounsworth, and J. Gray
> > Datatracker: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc4210bis/__;!!FJ-Y8qCqXTj2!ZfglpvZO2Y3mBLWRXUoDUaN1hOLay7j2uwWMW_rntVjbNGcOxV4_Td8D3-6I3U6KfRBd-3ZHALhIx_HVsn1X81_9yqch$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-rfc4210bis/__;!!FJ-Y8qCqXTj2!ZfglpvZO2Y3mBLWRXUoDUaN1hOLay7j2uwWMW_rntVjbNGcOxV4_Td8D3-6I3U6KfRBd-3ZHALhIx_HVsn1X81_9yqch$> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6712bis/__;!!FJ-Y8qCqXTj2!ZfglpvZO2Y3mBLWRXUoDUaN1hOLay7j2uwWMW_rntVjbNGcOxV4_Td8D3-6I3U6KfRBd-3ZHALhIx_HVsn1X80xkeWvk$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-rfc6712bis/__;!!FJ-Y8qCqXTj2!ZfglpvZO2Y3mBLWRXUoDUaN1hOLay7j2uwWMW_rntVjbNGcOxV4_Td8D3-6I3U6KfRBd-3ZHALhIx_HVsn1X80xkeWvk$>>
> > 
> > Title: Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
> > Authors: H. Brockhaus, D. von Oheimb, M. Ounsworth, and J. Gray
> > Datatracker: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6712bis/__;!!FJ-Y8qCqXTj2!ZfglpvZO2Y3mBLWRXUoDUaN1hOLay7j2uwWMW_rntVjbNGcOxV4_Td8D3-6I3U6KfRBd-3ZHALhIx_HVsn1X80xkeWvk$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-rfc6712bis/__;!!FJ-Y8qCqXTj2!ZfglpvZO2Y3mBLWRXUoDUaN1hOLay7j2uwWMW_rntVjbNGcOxV4_Td8D3-6I3U6KfRBd-3ZHALhIx_HVsn1X80xkeWvk$>
> > 
> > 
> > Should the LAMPS WG ask the IESG to publish these two documents as Standards-Track RFCs?  Please respond to this WG Last Call by 20 June 2024.
> > 
> > For the LAMPS WG Chairs,
> > Russ
> > 
>  
> _______________________________________________
> Spasm mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>