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

[Daniel Harkins <[e-mail]>]

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