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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Considering the usefulness of PKEX on one hand, and the fact that the benefits of security proofs in general are limited in practice – I support adoption of this document/protocol by CFRG.

 

(Yes, all things equal – it’s better to have security proofs than not to… But to me at least absence of the proofs is not necessarily a show-stopper.)

 

From: Cfrg <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Subject: Re: [Cfrg] Adoption call for draft-harkins-pkex-05

 

Dan,

 

I'm not sure what your argument is here. I agree that it's not like there's some fully worked out alternative proposal, but I don't think that's an argument for adopting this one. If your argument is that there's nothing mature enough here to take on, you'll get no argument from me.

 

-Ekr

 

 

 

 

 

On Mon, Aug 6, 2018 at 10:58 AM, Daniel Harkins <[e-mail]> wrote:


 About "commodity tools", there were two complaints raised:

  1. PKEX hashes the user identity with the password and uses the result
     with the role-specific constant while SPAKE2 does not;
  2. PKEX should just have a generic proof-of-possession protocol after the PAKE.

The implication being you combine these two and voila, something better than PKEX
because it's just using known tools to do this and is not rolling new crypto.

  Regarding the first, it's a draft that will be a work item of the research
group. If the consensus of the group is to edit the draft then the draft gets
edited to reflect the consensus of the group.

  Regarding the second, the suggestion was to do this:

    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)

Now I'm pretty sure that is not a generic commodity tool for doing proof-of-possession
so I'm not sure what complaint is. That proof-of-possession is more complicated than
what PKEX does, has more moving parts in the form of new ephemeral keys, does not
actually seem to prove possession of the private key, and I'd wager does not have a
security proof (Eric's final complaint about PKEX). 

  The request is not to rubber stamp the imprimatur of the CFRG on a document,
it is to adopt a document as a work item of the research group. With that in mind,
I have updated PKEX to incorporate the first suggestion (don't hash the ID with the
password). The current version is -06, it's in the repository. Please take a look and
consider its adoption.

  thanks,

  Dan.

On 8/5/18 6:47 AM, Eric Rescorla wrote:

I concur with Richard and Martin. Given that this will happen only infrequently, what's the advantage over plugging together commodity tools.

 

FWIW, while I recognize that the CFRG does not exist solely to support IETF protocols, I'm not seeing a lot of demand for this in the IETF.

 

In addition to the above, I note that the final line of the security considerations says "There is no proof of security of PKEX at this time." That seems like a pretty big concern. We're moving towards wanting security proofs for IETF protocols, and I'd generally expect that a lot of the value of CFRG is that it would produce primitives with high levels of assurance.

 

For these reasons, I would not support adoption.

 

-Ekr

 

 

On Thu, Apr 12, 2018 at 7:15 PM, Martin Thomson <[e-mail]> wrote:

Richard has summarized my own reservations with this and the
composition of existing primitives makes a lot of sense.  We're seeing
a relative explosion in the number of cryptographic tools available of
late, and this is a clear example of where we can make an engineering
decision to use existing tools rather than build new ones.  I
recognize that this isn't the IETF, but that doesn't make that any
less valid a choice.

FWIW, the lack of support for anything other than DSA and ECDSA is
also a major problem. DSA is basically non-existent in practice.  What
about Ed25519/Ed448?


On Fri, Apr 13, 2018 at 11:38 AM, Richard Barnes <[e-mail]> wrote:
>
>
> On Thu, Apr 12, 2018 at 7:52 PM, Dan Harkins <[e-mail]> wrote:
>>
>>
>>
>> On 4/12/18 6:21 AM, Richard Barnes wrote:
>> [snip]
>>
>>
>> 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
>>
>>
>>   So? The password is still used. Are you saying this is not SPAKE2
>> anymore?
>>
>> - The key shares from SPAKE2 are re-used for the proof of possession
>>
>>
>>   There needs to be some demonstration that the key is used "live" in the
>> exchange
>> otherwise you're not really proving possession. In your sketch below
>> (which I
>> admittedly don't understand 100%) you are introducing yet another
>> Diffie-Hellman
>> with Eph_A and Eph_B which I guess are used with the private analogs of
>> Pub_B
>> and Pub_A, respectively, to produce K_DH_B and K_DH_A, respectively.
>>
>>   I don't see the value of treating the PAKE a closed some black box.
>
>
> The benefits are the typical "don't roll your own crypto" benefits --
> generality, code re-use, and analysis re-use.  If you have a general "insert
> proof of possession here" slot, you can address keys from any DH group (even
> if it can't do SPAKE) or even signing keys.   You can take an SPAKE
> implementation that has a "password in, key out" interface and re-use it.
> And when you're trying to prove the properties of the system, you can treat
> the "black box" sub-units as things with known properties; you don't have to
> worry about whether re-using a key share will undermine some property.
>
> It seems like you're trading off 1 DH key generation per side (the
> incremental cost of the sketch below over PKEX) against a lot of work to
> analyze this thing and more difficulty implementing.  I'm just saying that
> trade-off doesn't seem like a good deal to me.  (If I were the chairs, I
> might consider whether this merits the group's time, given that the can be
> solved with existing primitives at not much cost.)  If others feel it is
> worthwhile, though, I'm not going to stand in the way.
>
> --Richard
>
>
>>
>> It already
>> has a perfectly good ephemeral Diffie-Hellman share which I am putting to
>> good use
>> instead of ignoring which necessitates generation of yet another ephemeral
>> Diffie-Hellman share.
>>
>> 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.
>> """
>>
>>
>>   Right, it expressly includes DSA keys.
>>
>> And maybe add a clearer explanation than "due to the nature of the
>> exchange".
>>
>>
>>   OK, good comment. That is overly vague.
>>
>>   Dan.
>>
>> --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.
>>>
>>>
>>
>>
>
>

> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>

_______________________________________________
Cfrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg

 



_______________________________________________
Cfrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg
 


_______________________________________________
Cfrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg