Subject: Re: [Cfrg] SESPAKE password-authenticated key exchange protocol

From: Иван Лавриков <[email-masked]>
Date: Fri, 22 Jan 2016 20:49:31 +0300

Dear colleagues!

I want to discuss some issues about recently proposed Internet Draft describing SESPAKE protocol.
Most of them will be editorial. I will state my considerations in accordance with the text of the draft flow.
1. The Abstract (and the same sentences in the rest of the draft) - «attacks with trials of impersonation as one of subjects» is better to change to «attacks based on the impersonation of one of the subjects».
2. Table of Contents (and the name of the section) - section 3 name should be started with the uppercase letter.
3. Notations:
- (main issue) as we all know, it is inappropriate to use I-D as reference.
- during the definition of F functions the statement «the order of the subgroup» seems to be redundant according to the previously given notations.
- the usage of parameter «l» in this font scheme is greatly increase the difficulty of reading, it’s better to use other letters.
- what is the purpose of the definition of «int» function and «INT» function? What is the difference between them? Is this true that these functions are used to transform only strings of fixed length (and form) later in the text or there are any padding procedures?
- there are multiple definitions of F function.
- concatenation is defined to be used only with byte strings, is it necessary?
- is this true that coordinates of elliptic curve points always will be the byte strings or there assumed the existence of some padding procedure? What is the purpose of the bit representation statement if only the byte representation is used in the draft?
4. subsection 4.1:
- during the redefinition of point P it’s better to use the same notation for the terms «group» and «subgroup».
- «the set of distinct <…> in Section 5).» - redundant closing parenthesis.
Protocol parameters of subject A:
- if the value of PW is chosen from the set B_6, then |B_6| = (2^3)^6 < 10^6, so there is no subset of stated cardinality, it seems that parameter k must be greater or equal to 10.
- during the definition of points {Q_1, …, Q_N} it’s not quite clear that all of them must be corresponding to the same curve, that chosen from the set of curves supported by A.
- it's better to use the same notation for the terms «side» and «subject».
Protocol parameters of subject B:
- operation * was not defined.
- it's better to use the same notation for the terms «side» and «subject».
5. subsection 4.2 - during the definition of the range of parameter CLim_3 it’s better to add additional points: {10^3, 10^3+1, …, 10^5} or {10^3, 10^4, 10^5}.
6. subsection 4.3:
- it’s better to use «stages» or «steps» instead of «actions».
- Stages 8, 11 — it’s not quite clear how the uniform distribution should be implemented in the protocol.
- Stage 13 - operation *(mod q) was not defined.
- Stage 22 - what is the purpose of this place of Stage and not after the stage 12?
- Stage 27 - what is the purpose of this place of Stage and not after the stage 17?
- Note 3. - the word «HMAC» is used twice.
7. subsection 5:
-  the statement «subgroup order» seems to be redundant according to the previously given notations.
- previously the coordinates of elliptic curve points were in {} not in ().
- step 1. - what distribution is used during the choice of SEED value?
- notation H_len was not defined.
Thank you for your attention!
Best regards,
Ivan Lavrikov, Russian Federation, 
TC 26 Expert