[CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15

[Filippo Valsorda <[e-mail]>]

Section 9.1 asks for "unique strings identifying the protocol partners" which are not available in some protocols, but "loopback" attacks can be prevented even by much weaker identifiers, such as role identifiers ("client"/"server", "initiator"/"responder", "sender"/"receiver"). It would be good to mention they are useful and an option.

(This reminds me of how HKDF asks for an optional random salt, omitting to mention that a fixed application-specific salt is much better than nothing or than an attacker-controlled salt. This led to designs doing sub-optimal things when perfectly random salts were not an option.)

Also, I can't semantically parse this sentence, does A integrate B's party identifier in ADb or does B?

> Otherwise A SHOULD integrate its party identifiers in ADa and ADb, such that A integrates its identifier in ADa and B integrates its party identifier as part of ADb.

2025-12-08 10:31 GMT+01:00 Björn Haase <bjoern.haase=[e-mail]>:
> Hi Feng,
> 
> thank you for your feedback. So I’d like to summarize that the remaining aspect in our discussion is not a different view on the attacks or possible vulnerabilities. 
> The key point in our discussion seems to be a different point of  view regarding which extend remaining freedom is left to application designers and integrators.
> 
> Regarding CPace on large characteristic fields:
> Actually also Steve Thomas did suggest to add this two weeks ago. In fact in the editor team we intentionally refrained from adding anything except elliptic curves to the draft. The reason was that we did not want to offer further, possibly confusing options and because this case was not explicitly covered in the scientific papers for the proof papers.
> 
> As we received the request for discussing finite-field groups now from several people, I have just added a proposal text for an additional text in the github repo as part oft he security consideration. You will find the proposal here CPace, a balanced composable PAKE <https://cfrg.github.io/draft-irtf-cfrg-cpace/draft-irtf-cfrg-cpace.html#name-large-characteristic-finite>.
> 
> There I have also added a suggestion for addressing your fear that (probably malicious) people might be considering using the insecure mapping specified in the ISO standards for CPace in CPace, a balanced composable PAKE <https://cfrg.github.io/draft-irtf-cfrg-cpace/draft-irtf-cfrg-cpace.html#name-side-channel-attacks>.
> 
> Yours,
> 
> Björn
>  
> Mit freundlichen Grüßen | Best Regards
> 
> Dr. Björn Haase
> 
> 
> Senior Expert Electronics | TGREH Electronics Hardware
> 
> *Endress+Hauser Liquid Analysis*
> 
> Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
> Phone: [phone]
> [e-mail] | www.ehla.endress.com
> 
> 
> 
> 
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta
> Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Thomas Buer
> 
> 
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
> 
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis <https://www.de.endress.com/de/cookies-endress+hauser-website> nach.
> 
> 
>  
> 
> 
> 
> Disclaimer:
> 
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged
> material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities
> other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
> 
>  
> 
> 
> 
> *Von:* Hao, Feng <Feng.Hao=[e-mail]> 
> *Gesendet:* Freitag, 5. Dezember 2025 22:32
> *An:* Björn Haase <bjoern.m.haase=[e-mail]>; [e-mail]
> *Betreff:* [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>  
> Hi Bjorn,
>  
> I am not sure if your change in the wording makes any difference. For security critical details, you need to define them unambiguously in a complete spec. The word “should” doesn’t help here.
>  
> As an example, see how the revised SPEKE was specified in ISO/IEC 11770-4 (Figure 4, p. 7,  https://arxiv.org/pdf/1802.04900) Besides the finite field, ISO/IEC 11770-4 also includes an elliptic curve version of the SPEKE.
>  
> A known problem with the finite field implementation is that the hash-to-group function uses safe primes as the modulus and hence the long exponents. The cost of exponentiation with a long exponent is very high (many times than the exponentiation with short exponents). Your spec completely avoids the finite field, and only focuses on EC. That’s OK. But you may want to make this clear.
>  
> For the elliptic curve version of SPEKE, a hash-to-curve function is required. The hash-to-curve function in ISO/IEC 11770-4 (following from IEEE P1363.2) works with any curve suitable for cryptography, but it’s not constant time. In your spec, you use different hash-to-curve functions that are custom-built for only selected curves. 
>  
> When you say “All state-of-the art methods for realizing constant-time execution SHOULD be used”, this is ambiguous. If constant-time is regarded a security-critical feature, you may want to explicitly state that only constant-time H2C algorithms “shall” be used. Otherwise, there is no difference to the SPEKE spec in ISO/IEC 11770-4.
>  
> Cheers,
> Feng 
>  
> *From: *Björn Haase <bjoern.m.haase=[e-mail]>
> *Date: *Friday, 5 December 2025 at 18:49
> *To: *[e-mail] <[e-mail]>
> *Subject: *[CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
> 
> You don't often get email from bjoern.m.haase=[e-mail]. _Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>_
> 
> Dear Feng,
> 
> thank you for the constructive feedback. I agree with you in that we should probably use a more explicit phrasing regarding the recommendation of using
> party identifiers. Please have a look at the following change suggestion.
> 
> _https://author-tools.ietf.org/api/iddiff?doc_1=draft-irtf-cfrg-cpace&url_2=https://cfrg.github.io/draft-irtf-cfrg-cpace/draft-irtf-cfrg-cpace.txt_
> 
> I have also added a sentence referring to the "loopback" version of the relay attack variant that you mentioned where messages from A are relayed back to A.
> 
> Yours,
> 
> Am 05.12.2025 um 16:32 schrieb Hao, Feng:
>> Hi,
>>  
>> I was only trying to raise the point that the user identity is one of the critical parameters in PAKE (and any authenticated key exchanges in general), and it needs to be defined explicitly.
>>  
>> When the user identity is optional, we may have the following attack scenario, where Alice and Bob share a password, but an attacker (who doesn’t know the password) can impersonate Bob to Alice and successfully pass the password authentication. See Figure 1 (_https://eprint.iacr.org/2014/585.pdf_) for the illustration of this attack. The original SPEKE spec in ISO/IEC 11770-4 has been revised to prevent this attack.
>>  
>> This impersonation attack exploits the confusion of the identity, and therefore is a form of the “unknown key share” attack. The “unknown key share” attack is an established, generic term, and there are many forms of it.
>>  
>> This attack is different from the “relay attack” you described. In the setting of your relay attack, three parties, A, B, and C share the same password. That is a less common scenario. The impersonation attack described above is between a victim user and an active attacker; it’s more practical.
>>  
>> Cheers,
>> Feng
>>  
>> *From:* Björn Haase _<bjoern.haase=[e-mail]>_
>> *Sent:* 05 December 2025 11:52
>> *To:* Hao, Feng _<[e-mail]>_; Stanislav V. Smyshlyaev _<[e-mail]>_; CFRG _<[e-mail]>_
>> *Cc:* [e-mail]_; [e-mail]_
>> *Subject:* AW: [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>  
>> Dear Feng,
>>  
>> before responding in detail I am having the following processural topic before responding
>> to each individual point brought up in your post.
>>  
>> When discussing a mature draft revision on the list I'd like to suggest that we all stick
>> to the naming/nomenclature and definition as used in the respective draft.
>>  
>> IMO using consistent nomenclature when discussing mature drafts is very important.
>> Without knowledge on the different nomenclature in the scientific literature for the same
>> topic a non-expert reader of our posts on the list might be mislead.
>> Inconsistent nomenclature might even be misused for nudging a reader to fearing
>> that an attack was overlooked in a draft by the authors and reviewers, while the exact
>> topic was actually considered in depth under a different name and heading.
>>  
>> For the CPace draft this is relevant as the "unknown key share attack" from [1,2] that you
>> are referring to in your post is explicitly discussed in the draft under the name of
>> "relay attacks".
>>  
>> For comparison I'd like to cite the definitions of the respective attacks from the
>> different sources:
>>  
>> "unknown key share attack", citing from [2] Section 3:
>> "The second attack assumes that the user shares the same password with two servers, say S1
>> and S2. By relaying the messages between the client and S2, the attacker may trick the
>> client into believing that she shares a key with S1, but actually the key is shared
>> with S2. The authors [of [1], Tang and Mitchell] call this an “unknown key-share” attack.
>> They suggest to address this attack by including the server’s identifier into the
>> computation of g."
>>  
>> "relay attack", citing from draft-irtf-cfrg-cpace-15 Section 9.1:
>> "Incorporating party identifier strings is important for fending off relay attacks. Such
>> attacks become relevant in a setting where several parties, say, A, B and C, share the same
>> password PRS. An adversary might relay messages from an honest user A, who aims at
>> interacting with user B, to a party C instead. If no party identifier strings are
>> used and B and C share the same PRS value then A might be using CPace for establishing a
>> common ISK key with C while assuming to interact with party B."
>>  
>>  
>> Now regarding your comment and your "technical concerns" I have the following feedback:
>>  
>> >CPace (as defined in the original 2019 paper) differs from the original SPEKE
>> >protocol (proposed by Jablon in 1996) in that it adds session IDs to the key
>> >exchange process. As a result of this change, completing the 2019 CPace
>> >protocol in 1 round or two passes is impossible. By now, this should be
>> >clear to everyone.
>> > 
>> >The CPace protocol in draft-15 has removed the session IDs as mandatory data.
>> > 
>> >CPace in draft-15 has also removed the party identity as mandatory data. From
>> >Section 3.1, the party identity is optional; it “MAY also be the empty string”.
>> > 
>> >These changes essentially revert CPace to SPEKE in 1996 . However, the 1996 SPEKE
>> >is known to suffer from an unknown key-share attack due to the missing user
>> >identities. With the explicit specification of the user identity as OPTIONAL
>> >in draft-15, it seems that CPace would suffer from the same attack.
>> >See [1] for more details.
>>  
>> Your wording seems to suggest, that you believe that the CFRG community might have overlooked
>> a known "unknown key share" attack from the literature when writing the draft.
>> In fact the respective aspect is discussed in depth in the draft in section 9.1.
>> "Party identifiers and relay attacks". Because of the relevance the reader's attention in section
>> 3.1. is explicitly drawn to the details discussed in section 9.1.
>>  
>> You moreover seem to claim that the one and only way to address the topic of relay attacks
>> is the method that you have been developping for SPEKE in the ISO/IEC process in [3]:
>> >Fixing this attack requires making party identities mandatory and including them in-flow
>> >during the key exchange.
>> >In order to maintain one-round efficiency, the only solution is to include the party
>> >identities in the key derivation function in a clearly defined lexicographic order. This is
>> >exactly what has been done in ISO/IEC to fix this issue. See [2] for more details. The revised
>> > SPEKE protocol, based on [2], has been standardized in ISO/IEC 11770-4.
>>  
>> In fact at least two independent secure ways for authenticating party identifiers alongside
>> with the protocol are known from the literature for fending off the relay attack.
>> - Firstly there is the approach of [4] (proof for the UC model) (following the approach of [1]
>>   for SPEKE) of integrating the identities in the calculation of the generator.
>> - Secondly there is the method exposed in Section B.1 of [4] ("real or random" game-based
>>   proof) which corresponds to what you are suggesting in [3].
>>  
>> Both options are presented and discussed in section 9.1. of the draft together with the
>> respective advantages and drawbacks. We advise the application designer to give preference
>> to the first option with the respective reasons stated in section 9.1 and 9.11 and 3. and
>> alternatively recommend the second approach if the preferred first option could not be chosen
>> due to application constraints.
>>  
>> >I would recommend the CPace authors make the party identities mandatory, and explicitly
>> >include them in the key derivation function as done above.
>>  
>> I believe that our common objective at CFRG should be to fill the gap between theory and
>> application and give guidance on how to best integrate cryptographic protocols and primitives
>> in the respective application scenario. The CPace draft was requested to serve the application
>> scenarios that come up for the balanced PAKE use cases.
>>  
>> For the CPace draft this implies that CPace should not be considered to form a standalone
>> protocol but rather a building block which aims at being integrateable in different application
>> scenarios.
>>  
>> One objective of the CPace design was to allow for security analysis for such integration by
>> closely following the semantics used for proofs in the UC framework. This comes at the cost
>> of offering the option of hardening the protocol with the help of a unique session id.
>>  
>> Regarding application scenarios different settings were identified:
>> - For some application scenarios authenticating both party identities might be important. This
>>   seems to be the only viable "PAKE" application that you are having in mind.
>> - A second set of applications exist where it is only needed to make sure that both parties
>>   share the same PRS string. One of the example of this group is the use case discussed on
>>   this list for the "Magic Wormhole" application setting
>>   (see _https://mailarchive.ietf.org/arch/msg/cfrg/BBQ2gwCECu5ouTJjE_CE6d9Rg-0/_ ).
>> - In a third set of applications authentication of only one out of the server and client identity
>>   might be of relevance. One example might be a WIFI-Router login application where the client
>>   wants to authenticate the name of a WIFI hot-spot but the server might be willing to give
>>   access to any client in possesion of the password. This seems also be the application context
>>   considered in [1].
>> - Moreover for an application confidentiality of party identifiers might be important and sending
>>   party identities in clear-text alongside with the protocol messages might not be an option (e.g.
>>   as in the PAKE use-case targeted by PACE for identity cards).
>> - Some application's might want to facilitate UC security analysis by reducing the gap between
>>   the UC framework and the real-world protocol by explicitly deriving session ids. Some might
>>   not want to pay the additional price of a possibly required additional round.
>>  
>> Ultimately there are various decisions and requirements cannot be addressed on the CPace level but
>> as part of the assessment for the larger application setting.
>> The CPace draft does so by offering the application layer a small set of alternative approaches with
>> a clear guidance on how to best use this flexibility and which advantages and drawbacks come with
>> either option (Sections 3.1 to 3.3 and 9).
>>  
>> The alternative of doing so would have been to either leave people such as Brian Warner
>> (in _https://mailarchive.ietf.org/arch/msg/cfrg/BBQ2gwCECu5ouTJjE_CE6d9Rg-0/_) without any guidance
>> or to issuing one specific RFC for all distinct "symmetric" PAKE use-cases which would result
>> in **many** specification documents.
>>  
>> In this context it is also worth noting that I have had a discussion off-the-list with Steve Thomas
>> end of November regarding the CPace draft. Steve suggested to additionally impose the requirement
>> to the CPace protocol that the PRS input string should never be memorized in persistent storage and
>> shall be ephemeral and password stretching for deriving PRS should not be considered.
>> I responded that in the the specific application use-case that Steve had in mind this additional
>> constraint would be indeed a good idea, but that there were other application scenarios where
>> different choices might be appropriate.
>>  
>> IMO the challenge for the CFRG is to find a good compromise in between the options of ruling
>> out important application scenarios on the one extreme or for adding excessive complexity
>> that comes with security pitfalls. IMO there is just no right or wrong regarding this
>> topic.
>>  
>> I believe that the CPace draft as-is does implement an appropriate choice by leaving a small set of
>> options that come with clear guidance on how to best use them.
>> Specifically Brain Warner's use case has shown that there are valid applications where
>> identity-binding is a "non-issue" and I see our objective at CFRG to give guidance regarding PAKE
>> usage also for this set of application designers.
>>  
>> Actually IMO this aspect has been at the core of the feedback during the crypto review panel
>> reviews and considered during the process.
>>  
>> Yours,
>>  
>> Björn
>>  
>> [1] Q. Tang, C. Mitchell, “On the security of some password-based key agreement
>> schemes,” International conference on Computational Intelligence and Security
>> (CIS), LNCS Vol. 3802, pp. 149-154, 2005
>>  
>> [2] Feng Hao, Siamak F. Shahandashti, "The SPEKE Protocol Revisited"
>> _https://eprint.iacr.org/2014/585.pdf_
>>  
>> [3] Feng Hao, Roberto Metere, Siamak F. Shahandashti and Changyu Dong,
>> “Analysing and Patching SPEKE in ISO/IEC” _https://arxiv.org/pdf/1802.04900_
>>  
>> [4] Abdalla, M., Haase, B., and J. Hesse, "Security analysis of CPace",
>> n.d., _https://eprint.iacr.org/2021/114_.
>>  
>>  
>>  
>>  
>> Mit freundlichen Grüßen | Best Regards
>> 
>> Dr. Björn Haase
>> 
>> 
>> Senior Expert Electronics | TGREH Electronics Hardware
>> 
>> *Endress+Hauser Liquid Analysis*
>> 
>> Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
>> Phone: [phone]
>> [e-mail]_ | _www.ehla.endress.com_
>> 
>> 
>> Endress+Hauser Conducta GmbH+Co.KG
>> Amtsgericht Stuttgart HRA 201908
>> Sitz der Gesellschaft: Gerlingen
>> Persönlich haftende Gesellschafterin:
>> Endress+Hauser Conducta
>> Verwaltungsgesellschaft mbH
>> Sitz der Gesellschaft: Gerlingen
>> Amtsgericht Stuttgart HRA 201929
>> Geschäftsführer: Dr. Thomas Buer
>> 
>> 
>> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
>> 
>> Dieser Informationspflicht kommen wir mit folgendem _Datenschutzhinweis <https://www.de.endress.com/de/cookies-endress+hauser-website>_ nach.
>> 
>> 
>>  
>> 
>> Disclaimer:
>> 
>> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged
>> material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities
>> other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer.
>> This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
>> 
>>  
>> 
>> *Von:* Hao, Feng <_Feng.Hao=[e-mail]_>
>> *Gesendet:* Donnerstag, 4. Dezember 2025 22:37
>> *An:* Stanislav V. Smyshlyaev <[e-mail]_>; CFRG <[e-mail]_>
>> *Cc:* [e-mail]_; [e-mail]_
>> *Betreff:* [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>  
>> Hi,
>>  
>> I have a few comments and a technical concern about draft-15.
>>  
>> CPace (as defined in the original 2019 paper) differs from the original SPEKE protocol (proposed by Jablon in 1996) in that it adds session IDs to the key exchange process. As a result of this change, completing the 2019 CPace protocol in 1 round or two passes is impossible. By now, this should be clear to everyone.
>>  
>> The CPace protocol in draft-15 has removed the session IDs as mandatory data.
>>  
>> CPace in draft-15 has also removed the party identity as mandatory data. From Section 3.1, the party identity is optional; it “MAY also be the empty string”.
>>  
>> These changes essentially revert CPace to SPEKE in 1996 . However, the 1996 SPEKE is known to suffer from an unknown key-share attack due to the missing user identities. With the explicit specification of the user identity as OPTIONAL in draft-15, it seems that CPace would suffer from the same attack. See [1] for more details.
>>  
>> Fixing this attack requires making party identities mandatory and including them in-flow during the key exchange. In order to maintain one-round efficiency, the only solution is to include the party identities in the key derivation function in a clearly defined lexicographic order. This is exactly what has been done in ISO/IEC to fix this issue. See [2] for more details. The revised SPEKE protocol, based on [2], has been standardized in ISO/IEC 11770-4.
>>  
>> I would recommend the CPace authors make the party identities mandatory, and explicitly include them in the key derivation function as done above.
>>  
>> [1] “The SPEKE Protocol Revisited” _https://eprint.iacr.org/2014/585_
>> [2] “Analysing and Patching SPEKE in ISO/IEC” _https://arxiv.org/pdf/1802.04900_
>>  
>> Regards,
>> Feng
>>  
>> *From:* Stanislav V. Smyshlyaev <[e-mail]_>
>> *Sent:* 01 December 2025 12:02
>> *To:* CFRG <[e-mail]_>
>> *Cc:* [e-mail]_; [e-mail]_
>> *Subject:* [CFRG] Re: RGLC on draft-irtf-cfrg-cpace-15
>>  
>> Dear CFRG,
>>  
>> We have received only one response, so we've decided to extend the RGLC.
>> It will end on December 15th 2025.
>>  
>> If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email.
>>  
>> Regards,
>> Stanislav, Nick, Alexey (CFRG chairs)
>>  
>>  
>> On Mon, Nov 10, 2025 at 8:57 AM Stanislav V. Smyshlyaev <[e-mail]_> wrote:
>>> Dear CFRG participants,
>>> 
>>> This message is starting a 3-week RGLC on draft-irtf-cfrg-cpace-15 ("CPace, a balanced composable PAKE"), _https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace_, that will end on December 1st 2025. If you've read the document and think that it is ready (or not ready) for publication as an RFC, please send a message in reply to this email or directly to CFRG chairs ([e-mail]_). If you have detailed comments, these would also be very helpful at this point.
>>>  
>>> The CPace protocol was selected as a result of the PAKE selection process in CFRG in 2019; there were a lot of reviews of the protocol and the early versions of the draft, see _https://github.com/cfrg/pake-selection_ 
>>>  
>>> We've also got a review for a recent version of the draft from Karthikeyan Bhargavan on behalf of the Crypto Review Panel:
>>> _https://mailarchive.ietf.org/arch/msg/crypto-panel/995IVSGk1jSRKvKS4gH2iu66eUc/_
>>> The authors were later addressing the concerns in the further versions of the draft.
>>>  
>>> Thank you,
>>> Stanislav, for CFRG chairs
>>  
>> _______________________________________________CFRG mailing list -- [e-mail]_To unsubscribe send an email to [e-mail]_
>  
 <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virenfrei._www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>_
>  
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>