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

[Eric Rescorla <[e-mail]>]

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]>
>> <[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 [e-mail]://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>