Re: [Cfrg] Adoption call for draft-harkins-pkex-05

[Richard Barnes <[e-mail]>]

On Wed, Apr 11, 2018 at 8:32 PM, Dan Harkins <[e-mail]> wrote:

>
>   Hi Richard,
>
> On 4/11/18 2:58 PM, Richard Barnes wrote:
>
>
>
> On Wed, Apr 11, 2018 at 5:06 PM, Dan Harkins <[e-mail]> wrote:
>
>>
>>
>>   Hi Richard,
>>
>> On 4/11/18 11:07 AM, Richard Barnes wrote:
>>
> [snip]
>
> Assuming this is a useful problem to solve, it's not clear to me that this
>> is the best way to solve it.  For example, it seems like the parties could
>> perform a traditional PAKE, then send their preferred identities to each
>> other protected by the negotiated key.  Note that this is basically what
>> happens with the TLS-PAKE I-D that I submitted earlier today (
>> https://datatracker.ietf.org/doc/draft-barnes-tls-pake/), though in that
>> case, you can have either certified or uncertified keys.
>>
>>
>>   TLS-pake, yea! What used to be draft-ietf-tls-pwd-- certificate-less
>> authentication
>> for TLS-- is sitting in the RFC editor's queue waiting for the TLS
>> registry to get reworked.
>>
>>   PKEX is a little different though. You could do TLS-pake and use the
>> negotiated
>> key with an identity you pass but then you'd have to maintain a
>> multiplicity of
>> public keys, one for each server you did TLS-pake to, otherwise you void
>> the security
>> of TLS-pake. PKEX will allow me to share my single uncertified public key
>> with multiple
>> people (using different passwords, of course).
>>
>
> Thanks for the reminder of the proof-of-possession part.  i had gotten
> fixated on the PAKE part :)
>
> I guess what I don't understand here is the benefit of conjoining the
> primitives rather than composing them.  It seems like you would get the
> same effects here in the same number of RTTs with a straightforward
> combination of PAKE, sending identities, and a proof-of-possession protocol
> [1], all of which are already well-established.  Instead, you've mushed
> them all together.  That seems like it has some costs, e.g., the
> restriction to ECDSA when with a more composed design you could support
> arbitrary DH or signing keys.  What are the corresponding benefits?
>
>
>   I'm not sure where the mashup is. You have basically described PKEX. It
> does
> SPAKE2 and then it sends identities and a proof of possession protected by
> the
> PAKE shared secret.
>

What I mean is that in addition to just using the PAKE, you're also
changing its internals:

- Instead of using the password as input, PKEX hashes in the identities
- The key shares from SPAKE2 are re-used for the proof of possession

You're not treating the PAKE as a box that takes a password on one side and
emits a key on the other side.



> The limitations are that the two sides have to be exchanging
> keys from the same group and since they've already agreed on a group for
> their
> identity keys then they have to use the same one for the PAKE. Those were
> not
> seen as serious issues because such a restriction may already be imposed
> on the
> subsequent key exchange protocol (e.g. MQV), and it obviates the need to
> discuss
> what it means to exchange, for instance, a p521 public key over a PAKE
> that uses
> brainpool256. It cuts down on problematic options. That's the same reason
> that
> the hash algorithm and SIV key length are determined by the prime defining
> the
> group, less options that might be used poorly means a more robust and
> idiot-proof
> protocol.
>

I'll grant that you do get more rigidity from the conjunction.  But I'm not
sure that this is more effective than simply expressing the requirement in
prose.



>
>   Also, there is no restriction on ECDSA.
>

Maybe you should revise this text then :)

"""
Due to the nature of the exchange, only DSA ([DSS]) and ECDSA
   ([X9.62]) keys can be exchanged with PKEX.
"""

And maybe add a clearer explanation than "due to the nature of the
exchange".

--Richard



> In fact, Appendix A.2 has the SPAKE2
> role-specific elements for four standard DH groups and the Appendix talks
> about
> how to generate role-specific elements for other groups not enumerated.
>
> --Richard
>
> [1] Sketch:
>
> A->B: SPAKE-Kex
> B->A: SPAKE-Kex, SPAKE-Confirm, {ID_B, Pub_B, Eph_B}K_spake_B
> A->B: SPAKE-Confirm, {ID_A, Pub_A, Eph_A}K_spake_A, MAC(K_DH_A, transcript}
> B->A: MAC(K_DH_B, transcript)
>
> Note that at this point, it's starting to look simpler just to do TLS!
>
>
>   It's not really. There is running code for this protocol (and not just by
> me) and it's much simpler than TLS.
>
>   regards,
>
>   Dan.
>
>
>