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

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Aug 2018 06:47:04 -0700

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 <[email-masked]>
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 <[email-masked]> wrote:
> >
> >
> > On Thu, Apr 12, 2018 at 7:52 PM, Dan Harkins <[email-masked]>
> 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
> > [email-masked]
> > https://www.irtf.org/mailman/listinfo/cfrg
> >
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Daniel Harkins <[email-masked]>
Date: Mon, 06 Aug 2018 10:58:29 -0700

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:
> 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.
>
> 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.
>
> On Thu, Apr 12, 2018 at 7:15 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > On Thu, Apr 12, 2018 at 7:52 PM, Dan Harkins
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >>
>     >>
>     >> primitives rather than composing them.  It seems like you would
>     get the same
>     >> of PAKE, sending identities, and a proof-of-possession protocol
>     [1], all of
>     >> 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
>     >>>   I'm not sure where the mashup is. You have basically
>     described PKEX. It
>     >>> does
>     >>   There needs to be some demonstration that the key is used
>     "live" in the
>     >> exchange
>     > 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
>     > 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
>     > analyze this thing and more difficulty implementing.  I'm just
>     saying that
>     > might consider whether this merits the group's time, given that
>     the can be
>     >> 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.
>     >>
>     >>> 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
>     >>> brainpool256. It cuts down on problematic options. That's the
>     same reason
>     >>> that
>     >>> role-specific elements for four standard DH groups and the
>     Appendix talks
>     >>> about
>     >>>   It's not really. There is running code for this protocol
>     (and not just
>     >>> by
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.irtf.org/mailman/listinfo/cfrg>
>     >
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.irtf.org/mailman/listinfo/cfrg>
>
>
>
>

---

From: Christopher Wood <[email-masked]>
Date: Tue, 7 Aug 2018 09:59:08 -0700

Hi Dan,

On Mon, Aug 6, 2018 at 10:58 AM Daniel Harkins <[email-masked]> wrote:
>   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
>     A->B: SPAKE-Confirm, {ID_A, Pub_A, Eph_A}K_spake_A, MAC(K_DH_A,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
>   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.

Putting aside the issue of whether or not this should be done with
existing tools, I do not think the RG should adopt this document in
the absence of security analysis and a corresponding proof. Have you
(or anyone else) started work on this missing piece?

Best,
Chris

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Aug 2018 11:37:53 -0700

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 <[email-masked]> wrote:

>> On Fri, Apr 13, 2018 at 11:38 AM, Richard Barnes <[email-masked]>
>> <[email-masked]> wrote:
>> >
>> >
>> >> primitives rather than composing them.  It seems like you would get
>> the same
>> >>>   I'm not sure where the mashup is. You have basically described
>> PKEX. It
>> >>> does
> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 7 Aug 2018 19:07:28 +0000

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 <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
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

 

    A->B: SPAKE-Kex

  thanks,

  Dan.

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.

-Ekr

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

On Fri, Apr 13, 2018 at 11:38 AM, Richard Barnes <[email-masked]> wrote:
>
>
> On Thu, Apr 12, 2018 at 7:52 PM, Dan Harkins <[email-masked]> wrote:
>>
>>
>>
>> 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
>> 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
>>>   I'm not sure where the mashup is. You have basically described PKEX. It
>>> does
>>   There needs to be some demonstration that the key is used "live" in the
>> exchange
> 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
> 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
> analyze this thing and more difficulty implementing.  I'm just saying that
> might consider whether this merits the group's time, given that the can be
>> 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.
>>
>>> 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
>>> brainpool256. It cuts down on problematic options. That's the same reason
>>> that
>> not sure that this is more effective than simply expressing the requirement
>> in prose.
>>
>>
>>>
>>>
>>> role-specific elements for four standard DH groups and the Appendix talks
>>> about
>>>   It's not really. There is running code for this protocol (and not just
>>> by

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Aug 2018 19:27:22 +0000

> (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.)

Absolutely not, for adoption.  The RG might want to add one before publication, but that’s a discussion to have after adoption.

---

From: Greg Rose <[email-masked]>
Date: Tue, 7 Aug 2018 12:35:54 -0700

I'm not a proofs person myself, but I would imagine that (given how well understood the primitives are) it shouldn't be too hard for someone to assign a grad student to the problem. But most of us on this discussion are not academics, so don't have spare grad students...

I'm still for adoption.

Greg.

Phone/Signal:  +1 619 890 8236 
GPG/PGP:  1081A37C  232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

> On Aug 7, 2018, at 12:27 , Salz, Rich <rsalz=[email-masked]> wrote:
>