Re: [CFRG] IRSG review draft-irtf-cfrg-spake2-20

[Julia Hesse <[e-mail]>]

Dear Watson,

>> // - What does it mean to exchange messages symmetrically? (In the per-user M and N section)
>>      * Resolved. I suggest to remove "to have a symmetric variant" - it is not needed and might cause confusion (variant of what?)
> It is needed: Magic Wormhole uses this variant. And the concern about
> who uses M and who uses N in cases where it isn't clear is best
> addressed by using this variant.

Ah, apparently I got confused here: the draft is referring to SPAKE2 as 
a symmetric PAKE, and to the case of M=N as its symmetric variant. So 
you are completely right, the sentence in question should stay, but I 
would recommend referring to the case of M=N as "parallel variant" (or 
something else) instead of assigning two different meanings to the word 
"symmetric".

>> // - Beyond scalar multiplication being constant time, are there any other constant time considerations we should include?
>>      * Resolved
>>
>> // - Why is Ke not included in the test vectors? It may be redundant, but it seems useful as an additional sanity check.
>> // - There are currently no test vectors that include AAD -- should we add some?
>>      * I have not verified these two.
>>
>> // - Why is len() a little-endian output?
>>      * I agree with Watson to be consistent with Kerberos here
>>
>> // - Should we clarify that the transcript assumes a particular point encoding scheme, and that is to be defined by the calling application or implementation?
>>      * Resolved
>>
>> Some more comments, not related to the IRSG review, below.
>>
>> I was missing a minimal list of data that A and B can start SPAKE2 from: ciphersuite, pw, A, B, M, N - did I forget something? What about the output key length? This can be easily included in 3.2, replacing "A and B are provisioned with information such as..."
>>
>> The document does not specify who uses M and who uses N. In the M\neq N variant of the protocol, which is mostly described in this draft, this is relevant, since no analysis was conducted in case A sends both xM and xN (a solution that implementors are not unlikely to come up with). I would include an instruction in the RFC, e.g., that the application must ensure that M and N are assigned to A and B, e.g., by having them apply some lexicographically-first-... rule.
> I'm not sure I follow the issue. The sentence says 'A picks x randomly
> and uniformly from the integers in [0,p), and calculates X=x*P and
> S=w*M+X, then transmits pA=S to B.' Alice is hence the initiatior. If
> it's impossible to do this easily then one of the M=N variants should
> be used. Most protocols have an asymmetry here where one side is
> initiating a request and the other receiving. Happy to add clarifying
> text.
Ack to all. It would actually be good to clarify this in the draft: the 
M != N variant is for an initiator-responder variant, the M=N for a 
parallel variant that MUST (?) be used whenever the applicatoin cannot 
assign initiator and responder role to the parties. My concern was from 
a security perspective, from which we should avoid situation such as the 
following: a user generates pA wrt M, but then receives pB also 
generated wrt M, suddenly realizes that it is the responder, and 
*additionally* sends pA wrt N. This voids the security proof, so we need 
to be pretty clear here.

Best regards,
Julia

>> p.2
>> The KDF has only 3 inputs, but a fourth (key length L) is described in the text
>>
>> p.3
>> servers -> serves
>> flow figure should include "verify cA" and "verify cB", since it is a MUST.
>>
>> p.4
>> remove unnecessary variables T and S? E.g., directly set pB=w*N+Y.
> These editorial comments seem worthwile to fix. Side note to Colin: is
> there another set of reviews I should be waiting for at this stage? If
> not I should be able to fix these all pretty promptly.
>
> Sincerely,
> Watson Ladd
>
>
> --
> Astra mortemque praestare gradatim