Re: [Crypto-panel] Request for review: CPace

[Karthikeyan Bhargavan <[e-mail]>]

Hello All,

I spent a couple of days re-reading the CPace draft 10 (https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-10), the 2021 security analysis paper by Abdella, Haase, 
and Hesse (https://eprint.iacr.org/2021/114.pdf) and the process critique paper by Hao (https://eprint.iacr.org/2021/839.pdf) 
In particular, I looked at how CPace could be securely integrated into a protocol like TLS 1.3.

----
In 2019, we reviewed the original CPace proposal with colleagues at Inria Prosecco and our review raised three points on the original proposal:

1) CPace uses a unique connection identifier (CI) in the first message from the initiator to the responder to prevent relay attacks.
    It was not clear to us how this unique CI could be computed without adding a round-trip to the protocol.

2) CPace relies on a unique session identifier (sid) for multi-session security. This sid is also used in the first protocol message.
    Again, it was not clear to us how the two parties could agree on an sid without adding a round-trip to the protocol.

3) It was unclear whether key confirmation was needed or not.

It is worth noting that 1) and 2) are also pointed out as potential CPace defects in Hao’s critique.

----
After reviewing the latest CPace draft, I can confirm that these questions are now answered in the text:

Connection Identifier (CI)
- Section 3.1 now says that the CI is *optional*.
- In response to our review, the authors said that the CI could use network addresses (IP addresses and ports) which do not require a round-trip
- The authors also say that CI is not needed if the application protocol provides key confirmation, which e.g. TLS 1.3 does

Session Identifier (CI)
- Section 3.1 now says that the sid is *optional*.
- This section recommends that the two parties should jointly establish an sid before the connection (which does imply an extra round-trip, at least for TLS 1.3)
- It also says that the initiator can unilaterally generate a fresh sid and send it to the responder (which would not require an extra round-trip).

Key Confirmation
- Section 9.4 explicitly describes how to obtain Explicit Key Confirmation if needed
- Protocols like TLS 1.3 already provide key confirmation.

----
Given the above clarifications, the following security questions still remain:

- The multi-session security of CPace relies on a “jointly” generated unique sid.
  Does this proof still hold if the initiator unilaterally generates the sid?
  Couldn’t the responder be vulnerable to replay attacks in this setting?
  How would one adapt the proof to account for unilateral “sid”s?

- What is the recommended way of integrating CPace into (say) TLS 1.3?
  Does the ISK take the role of (EC)DHE shared secret in the key schedule?
  Does the ISK become an additional input that is combined with an (EC)DHE shared secret?
  The definition and format of transcript in CPace is not exactly the same as the TLS handshake transcript.
  Are these two to be merged? If so, the test vectors of CPace would no longer work.

It if of course not expected that the CPace draft should answer these questions with concrete designs and formal proofs, 
but it would be useful to the reader and implementor to learn the answers to these questions and know the pitfalls of
embedding CPace incorrectly into an application protocol.


Best regards,
Karthik


 


> On Thu, Oct 5, 2023 at 10:51 AM Stanislav V. Smyshlyaev <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi all,
>> 
>> We still need reviewers (three or four) for the CPace draft.
>> 
>> Since CPace was a winner of the PAKE selection process, we have to be 100% sure that all concerns have been properly addressed.
>> 
>> Bjoern, Russ, Karthik, we will be happy to receive reviews from you (taking into account your reviews provided during the PAKE Selection process).
>> 
>> Chloe, Julia, Jean-Philippe, Scott, if some of you could review the CPace draft, despite the fact that you've just reviewed the OPAQUE draft (thanks a lot once again for this!), that would be amazing as well.
>> 
>> Best regards,
>> Stanislav (for CFRG chairs)
>> 
>> On Mon, Sep 25, 2023 at 3:17 PM Stanislav V. Smyshlyaev <[e-mail] <mailto:[e-mail]>> wrote:
>>> Dear Crypto Panel Experts,
>>> 
>>> The chairs would like to ask the Crypto Panel to provide three (or more) reviews for the CPace draft, "CPace, a balanced composable PAKE", draft-irtf-cfrg-cpace-10 (https://datatracker.ietf.org/doc/draft-irtf-cfrg-cpace/).
>>> 
>>> The CPace protocol was selected as a result of the PAKE selection process in CFRG (as well as the OPAQUE protocol which has recently been reviewed by the Panel). 
>>> 
>>> There were a lot of reviews of the protocol and the early versions of the draft, see https://github.com/cfrg/pake-selection
>>> There were several important questions in those reviews which had to be addressed during the evolution of the draft in CFRG: some of them are underlined in the following paper: https://eprint.iacr.org/2021/839.pdf
>>> 
>>> Hence we would like to ask the reviewers to pay a lot of attention to reviewing this draft, trying to take into account as many considerations provided in the previous reviews as possible.
>>> 
>>> Stanislav (on behalf of the CFRG Chairs)