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

[Eric Rescorla <[e-mail]>]

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
>