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

From: Alexey Melnikov <[email-masked]>
Date: Sun, 8 Apr 2018 12:41:58 +0100

Dear CFRG participants,
This message is starting a 2 weeks adoption call for
draft-harkins-pkex-05 (Public Key Exchange). From the document's
Introduction:

   [RFC7250] further states that "the main security challenge [to using
   'raw' public keys] is how to associate the public key with a specific
   entity.  Without a secure binding between identifier and key, the
   protocol will be vulnerable to man-in-the- middle attacks."

   The Public Key Exchange (PKEX) is designed to fill that gap: it
   establishes a secure binding between exchanged public keys and
   identifiers, it provides proof-of-possession of the exchanged public
   keys to each peer, and it enables the establishment of trust in
   public keys that can subsequently be used to facilitate
   authentication in other authentication and key exchange protocols.
   At the end of a successful run of PKEX the two peers will have trust
   in each others exchanged public keys and also share an authenticated
   symmetric key which may be discarded or used for another purpose.

The adoption call will last for 2 weeks and will end on April 22nd.

Thank you,
Kenny and Alexey

---

From: Greg Rose <[email-masked]>
Date: Sun, 8 Apr 2018 21:55:58 -0700

I support adoption. I made a number of comments offline that have been addressed.

Greg.

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

> On Apr 8, 2018, at 4:41 , Alexey Melnikov <[email-masked]> wrote:
> 
> Dear CFRG participants,
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Mon, 9 Apr 2018 08:46:08 +0300

Dear colleagues,

I support adoption. The protocol has smart architecture, it suits the core
principles of RFC 8125.
We've had a number of discussions with Dan Harkins, he completely
understands, what is important for constructing a good PAKE, so I'm
absolutely sure that several remaining important issues with the document
will be solved.

Best regards,
Stanislav

---

From: Dan Brown <[email-masked]>
Date: Tue, 10 Apr 2018 17:59:45 +0000

I'm seeing two minor issues to be resolved before adoption:
1. "Public key exchange" is a totally non-specific name, so much so, that I
oppose adoption under this name.  Public key exchange could mean
Diffie-Hellman key agreement, for example.  If PKEX has been deployed in
some places, the name should be updated retroactively.  (Sorry that this is
merely a terminology issue (as in the color of bikeshed, not the bikeshed
itself.)
2. What is the problem being solved here?  For example, I think that TLS
will or does offer PSK authentication.  So, why not just do an out-of-band
PAKE to establish a PSK, then use PSK-authenticated TLS.  So, to rephrase my
question: is there some security defect with PSK-authenticated TLS that PKEX
solves?  Maybe this was discussed already, sorry if I missed it (and am out
of order).
Otherwise, I do not have much of an opinion in either direction.

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Sunday, April 8, 2018 7:42 AM
To: [email-masked]
Subject: [Cfrg] Adoption call for draft-harkins-pkex-05

Dear CFRG participants,

Thank you,
Kenny and Alexey

---

From: Greg Rose <[email-masked]>
Date: Tue, 10 Apr 2018 12:56:27 -0700

> On Apr 10, 2018, at 10:59 , Dan Brown <[email-masked]> wrote:
> 

No comment on your first point. For this one, though, I think the point is to have a standard that allows reaching the goal without riding the elephant of TLS to get there.

Greg.

---

From: Dan Brown <[email-masked]>
Date: Tue, 10 Apr 2018 20:46:35 +0000

A third very minor issue (again terminology, and arguably more pedantic):
3. The PKEX I-D uses the word "trust" often. It seems to me that is not an
equivalent in strength trust to a more conventional public-key certificate
(or a distributed web of trust either).  I think this needs clarification in
the draft.  I expand on the difference below, in two closely related
sub-issues.
3a. First, if Bob lost his secret password, or has a bad RNG, then Eve may
be able to impersonate Alice to Bob, even if Alice system's is entirely
uncompromised.  In regular authenticated key exchange, this type of attack
is called key-compromise impersonation (KCI).  I guess KCI applies to every
PAKE, which is fair enough.  But PKEX has farther aims than a just PAKE,
kind of a sub-PKI. (Is PKEX a play on PKIX?)  But in a PKI, relying parties
can "trust" public keys, such as code signing keys, without having any
secrets at all to guard.  So, in some sense there is lesser degree of trust
provided by a PKI.  
3b. Second, and this issue is an extension of the first (not independent of
it), I would argue that part of "trust" in a public key includes an ability
to trust its use in non-repudiable signed transaction.  Because of the KCI
threat, Alice could do PKEX with Bob, sign a message with her key A, then
try to repudiate.  Bob will not be able to prove to anybody A is Alice's
key, because he could have generated A himself, as if Bob did a KCI attack
on himself.  So, Bob will not be able to trust Alice as much as usual in a
PKI.

At the moment I don't have a concrete suggestion to correct this
terminology.  Also, I forget if PKI spec use the word "trust" or something
else.

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Sunday, April 8, 2018 7:42 AM
To: [email-masked]
Subject: [Cfrg] Adoption call for draft-harkins-pkex-05

Dear CFRG participants,

Thank you,
Kenny and Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Apr 2018 22:49:10 -0500

Noting that I haven't read the draft terribly recently, I
nonetheless charge ahead...

> the draft.  I expand on the difference below, in two closely related

I think that we could replace "trust" with "binding between identity
and raw public key" to help us understand the intent, though the
resulting language from a global search-and-replace would probably
be pretty stilted.

> kind of a sub-PKI. (Is PKEX a play on PKIX?)  But in a PKI, relying parties

(I always assumed PKEX was a play on PKIX, even if that was not the
author's intention.)

> terminology.  Also, I forget if PKI spec use the word "trust" or something

I think about it as being that a local party has trust that a
given raw public key belongs to a particular peer identity.
But there's not a huge need to use the word "trust"; we could talk
about "confidence that a key belongs to a named party" or similar.

-Ben

---

From: Dan Brown <[email-masked]>
Date: Wed, 11 Apr 2018 15:25:22 +0000

A 4th issue/question, not really about terminology, but more definitional,
also a bit uncertain (I'm tiring out on this one):

The authentication phase of PKEX is basically just SPAKE2, and goes from a
weak password to a strong symmetric key z.  I'm still fine with this phase,
modulo (1) subtle differences in PAKEs that I do not yet understand and (2)
questions whether passwords are properly in scope of IETF, since they don't
scale well globally, etc.

The reveal phase does not seem to add obvious value.  It seems to be almost
the opposite of static Diffie-Hellman. We can switch back and forth between
a secret symmetric key z and authenticated asymmetric keys A,B.   What can
Alice and Bob with A and B that they could not already do with z.
Authenticate messages?  They can use HMAC with z - instead of (repudiable)
signatures or OTR with A and B.  Send each other secret messages? They can
use AES, etc, with z, - instead of ECIES with A or B?   Generate yet more
symmetric keys? They can use KDFs, PRFs, wrapped keys, etc., - instead of
Diffie-Hellman or MQV.  

If some IETF protocols use public keys but lack any means for Alice and Bob
to leverage their pre-shared secret (password, etc.), then I guess could
PKEX retro-fit or shoe-horn it in.  But then one could also, maybe just as
modularly, run a tunnel based on SPAKE2 and z inside (or outside) such an
inflexible IETF protocol to get the same effect.  For example, an online
bank could run a CA-authenticated TLS tunnel, and then run, at a higher
layer, a SPAKE2-protected connection inside the TLS tunnel, etc.

Please note, although I am deliberately trying to be extra-critical here, I
am also trying not to be contrarian.

-----Original Message-----
From: Dan Brown 
Sent: Tuesday, April 10, 2018 4:47 PM
To: Dan Brown <[email-masked]>; Alexey Melnikov
<[email-masked]>; [email-masked]
Subject: RE: [Cfrg] Adoption call for draft-harkins-pkex-05

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Sunday, April 8, 2018 7:42 AM
To: [email-masked]
Subject: [Cfrg] Adoption call for draft-harkins-pkex-05

Dear CFRG participants,

Thank you,
Kenny and Alexey

---

From: Dan Harkins <[email-masked]>
Date: Wed, 11 Apr 2018 08:28:12 -0700

Hi Dan,

> the draft.  I expand on the difference below, in two closely related

   By trust I mean: 1) that the public key received is the public key sent;
2) that the public key is bound to an authenticated identity; and 3) that
the sender proves possession of the corresponding private key. They can
now be used in a regular key exchange protocol-- like IKE or TLS-- that is
authenticated with raw public keys. To authenticate with raw public keys
you need some sort of "trust" in the public key. That's what PKEX provides.

> secrets at all to guard.  So, in some sense there is lesser degree of trust

   The secret only needs to be guarded until PKEX is run, once it has
successfully concluded the secret can be exposed and it will not affect
the security of the exchange. The exchanged keys can still be trusted
when subsequently used.

   I agree that PKEX provides a lesser degree of trust provided by a 
PKI. It's
not supposed to be a replacement, just a way to gain trust in a raw 
public key
which heretofore has always been done "in a manner outside the scope of the
protocol."

   That said, when I enroll in a CA I need to authenticate myself to it
somehow. It doesn't just give out certificates to anyone who provides a
name and a public key. So whatever credential I use to prove I am who I
say I am at enrollment time is analogous to password used in PKEX.

> on himself.  So, Bob will not be able to trust Alice as much as usual in a

   That's a great point. It's sort of the flip side of the anonymity that
PKEX provides to subsequent use of the public key. The keys are only known
and trusted by the two peers that ran PKEX. Anyone who views a key exchange
using a raw public key would not be able to determine who engaged in the
protocol and the whole exchange would be completely deniable.

   This is needs to be explained further in the draft.

> terminology.  Also, I forget if PKI spec use the word "trust" or something

   If you come up with a different word please send it to the list. I still
think "trust" is the right word, with the proviso above.

   regards,

   Dan.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 11 Apr 2018 15:32:17 +0000

I support adopting and publishing this draft.

--

Regards,

Uri Blumenthal

From: Cfrg <[email-masked]> on behalf of Dan Harkins <[email-masked]>
Date: Wednesday, April 11, 2018 at 11:29
To: CFRG <[email-masked]>
Subject: Re: [Cfrg] Adoption call for draft-harkins-pkex-05

  Hi Dan,

  I agree that PKEX provides a lesser degree of trust provided by a PKI. It's
not supposed to be a replacement, just a way to gain trust in a raw public key
which heretofore has always been done "in a manner outside the scope of the
protocol."

 

  regards,

  Dan.

 
-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Sunday, April 8, 2018 7:42 AM
To: [email-masked]
Subject: [Cfrg] Adoption call for draft-harkins-pkex-05
 
Dear CFRG participants,

 
 
Thank you,
Kenny and Alexey

---

From: Dan Harkins <[email-masked]>
Date: Wed, 11 Apr 2018 09:25:05 -0700

Hi Dan,

> scale well globally, etc.

   No they don't. They scale about as well as raw public keys :-) But they
are in scope.

> symmetric keys? They can use KDFs, PRFs, wrapped keys, etc., - instead of

   Yes, z (or keys derived from it) can be used for all sorts of things 
while
Alice and Bob are still talking to each other. This is mentioned at the end
of section 5.2.

   The value of the reveal phase is confirmation of SPAKE2 and gained trust
in the public keys. The ability to successfully unwrap a received message
authenticates the SPAKE2 exchange. The identity associated with the password
is confirmed. The guarantees that AES-SIV provide mean that the received
public key could only be sent by someone who knows z (and there are only
two people in the world that know z at that time) so the received key has
integrity and it is bound to the identity authenticated by SPAKE2. Finally,
proof of possession is provided by the peer using its private key with the
ephemeral share sent in SPAKE2 to symmetrically "sign" information binding
it to the exchange.

> am also trying not to be contrarian.

   Understood. And appreciated!

   regards,

   Dan.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 11 Apr 2018 14:07:13 -0400

Just to confirm I understand here, the scenario this is intended to address
is as follows (?):

- Two parties share a password
- Each party wishes to allow the other to assert an identity, where the
assertion is authenticated by the password

I would be interested to learn why people think this a useful problem to
solve.  If you have a system for provisioning passwords, couldn't you just
as well provision key fingerprints?  If you care about identities (say if
you're using the password to authenticate a group, and you want identities
to distinguish individual members), then why are you OK with raw assertion,
allowing anyone to claim any identity?

Assuming this is a useful problem to solve, it's not clear to me that this
is the best way to solve it.  For example, it seems like the parties could
perform a traditional PAKE, then send their preferred identities to each
other protected by the negotiated key.  Note that this is basically what
happens with the TLS-PAKE I-D that I submitted earlier today (
https://datatracker.ietf.org/doc/draft-barnes-tls-pake/), though in that
case, you can have either certified or uncertified keys.

This latter question seems important for the adoption question.  If this is
just a usage of a PAKE, then it's a protocol question more suited to IETF.
Only if there's a need to entangle the identity in the PAKE would we need
this group to opine.

On Wed, Apr 11, 2018 at 12:25 PM, Dan Harkins <[email-masked]> wrote:

> To: Dan Brown <[email-masked]> <[email-masked]>; Alexey Melnikov<[email-masked]> <[email-masked]>; [email-masked]
> From: Cfrg [mailto:[email-masked] <[email-masked]>] On Behalf Of Dan Brown
> To: Alexey Melnikov <[email-masked]> <[email-masked]>; [email-masked]
> From: Cfrg [mailto:[email-masked] <[email-masked]>] On Behalf Of Alexey Melnikov
> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
>

---

From: Dan Harkins <[email-masked]>
Date: Wed, 11 Apr 2018 14:06:39 -0700

Hi Richard,

On 4/11/18 11:07 AM, Richard Barnes wrote:
> Just to confirm I understand here, the scenario this is intended to 
> address is as follows (?):
>
> - Each party wishes to allow the other to assert an identity, where 
> the assertion is authenticated by the password

   Each party wishes to stop using passwords and migrate to public keys. 
Imagine
they want to do MQV or IKE or some other protocol that uses uncertified 
public
keys.

> I would be interested to learn why people think this a useful problem 
> to solve.  If you have a system for provisioning passwords, couldn't 
> you just as well provision key fingerprints?  If you care about 
> identities (say if you're using the password to authenticate a group, 
> and you want identities to distinguish individual members), then why 
> are you OK with raw assertion, allowing anyone to claim any identity?

   Yes, you can provision key fingerprints but it's difficult to manage 
256-bit
hexidecimal strings which is why people always look to some other 
technique. You
could use the "Drunken Bishop" algorithm to make a graphical 
representation of
the public key. The security of that is not well-established though 
(i.e. how
hard is it to come up with a key that makes a drunken bishop walk that 
looks enough
like yours to make people think my key is yours? I don't think anyone 
knows exactly).
Humans make mistakes and PKEX is robust and allows for simple, easy to 
provision
credentials to be used.

   The reason a raw assertion is OK is because you and I are agreeing on 
what
the password is so we can decide what identity I will accept. But I will 
know
that it's you because you're the only guy I shared the password with.

> Assuming this is a useful problem to solve, it's not clear to me that 
> this is the best way to solve it.  For example, it seems like the 
> parties could perform a traditional PAKE, then send their preferred 
> identities to each other protected by the negotiated key.  Note that 
> this is basically what happens with the TLS-PAKE I-D that I submitted 
> earlier today 
> (https://datatracker.ietf.org/doc/draft-barnes-tls-pake/), though in 
> that case, you can have either certified or uncertified keys.

   TLS-pake, yea! What used to be draft-ietf-tls-pwd-- certificate-less 
authentication
for TLS-- is sitting in the RFC editor's queue waiting for the TLS 
registry to get reworked.

   PKEX is a little different though. You could do TLS-pake and use the 
negotiated
key with an identity you pass but then you'd have to maintain a 
multiplicity of
public keys, one for each server you did TLS-pake to, otherwise you void 
the security
of TLS-pake. PKEX will allow me to share my single uncertified public 
key with multiple
people (using different passwords, of course).

   Also, I don't want to have to do TLS to obtain trust in a public key.

   regards,

   Dan.
> This latter question seems important for the adoption question.  If 
> this is just a usage of a PAKE, then it's a protocol question more 
> suited to IETF.  Only if there's a need to entangle the identity in 
> the PAKE would we need this group to opine.
>
>
> On Wed, Apr 11, 2018 at 12:25 PM, Dan Harkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>       Hi Dan,
>
>       Yes, z (or keys derived from it) can be used for all sorts of
>     things while
>>     To: Dan Brown<[email-masked]> <mailto:[email-masked]>; Alexey Melnikov
>>     <[email-masked]> <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
>>     To: Alexey Melnikov<[email-masked]> <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
>>     To:[email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.irtf.org/mailman/listinfo/cfrg>
>>
>>
>>     [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: Richard Barnes <[email-masked]>
Date: Wed, 11 Apr 2018 17:58:58 -0400

On Wed, Apr 11, 2018 at 5:06 PM, Dan Harkins <[email-masked]> wrote:

> the public key. The security of that is not well-established though (i.e.
> how

OK, so the one-identity-per-password thing seems pretty important.  It
would be good to make that really clear in the document.  And maybe note
that the side provisioning the passwords can be stateless by making the
password a function of the expected identity (e.g., a MAC using a key known
only to the provisioning party).

> of TLS-pake. PKEX will allow me to share my single uncertified public key
> with multiple

Thanks for the reminder of the proof-of-possession part.  i had gotten
fixated on the PAKE part :)

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?

--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!

> This latter question seems important for the adoption question.  If this
> is just a usage of a PAKE, then it's a protocol question more suited to
> IETF.  Only if there's a need to entangle the identity in the PAKE would we
> need this group to opine.
>
>

---

From: Dan Harkins <[email-masked]>
Date: Wed, 11 Apr 2018 17:32:39 -0700

Hi Richard,

On 4/11/18 2:58 PM, Richard Barnes wrote:
>
>
> On Wed, Apr 11, 2018 at 5:06 PM, Dan Harkins <[email-masked] 
[snip]
>
>>     Assuming this is a useful problem to solve, it's not clear to me
>>     that this is the best way to solve it.  For example, it seems
>>     like the parties could perform a traditional PAKE, then send
>>     their preferred identities to each other protected by the
>>     negotiated key.  Note that this is basically what happens with
>>     the TLS-PAKE I-D that I submitted earlier today
>>     (https://datatracker.ietf.org/doc/draft-barnes-tls-pake/
>>     <https://datatracker.ietf.org/doc/draft-barnes-tls-pake/>),
>>     though in that case, you can have either certified or uncertified
>>     keys.
>
>       TLS-pake, yea! What used to be draft-ietf-tls-pwd--
>     certificate-less authentication
>       PKEX is a little different though. You could do TLS-pake and use
>     the negotiated
>     public keys, one for each server you did TLS-pake to, otherwise
>     you void the security
>     of TLS-pake. PKEX will allow me to share my single uncertified
>     public key with multiple
> 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. 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.

   Also, there is no restriction on ECDSA. 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.

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Apr 2018 09:21:57 -0400

On Wed, Apr 11, 2018 at 8:32 PM, Dan Harkins <[email-masked]> wrote:

>   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
- The key shares from SPAKE2 are re-used for the proof of possession

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
> identity keys then they have to use the same one for the PAKE. Those were
> not
> 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

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.
"""

And maybe add a clearer explanation than "due to the nature of the
exchange".

--Richard

> In fact, Appendix A.2 has the SPAKE2
> role-specific elements for four standard DH groups and the Appendix talks
> about

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 12 Apr 2018 09:34:30 -0400

> On Apr 12, 2018, at 09:21, Richard Barnes <[email-masked]> wrote:
> 
>   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:
> 

I’d rather type a 20-character password than 256-character hash, thank you!

I prefer keeping PKEX as it is now.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Apr 2018 09:48:06 -0400

> I prefer keeping PKEX as it is now.

None of the alternatives being discussed here would entail a user interface
change.

Also, to be precise, a SHA-256 hash is only 64 characters, if you do it in
hex ;)

--RIchard

---

From: Dan Harkins <[email-masked]>
Date: Thu, 12 Apr 2018 16:52:32 -0700

On 4/12/18 6:21 AM, Richard Barnes wrote:
[snip]
> - 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. 
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.
>
>     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
>     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.
>
>

   Right, it expressly includes DSA keys.

> And maybe add a clearer explanation than "due to the nature of the 

   OK, good comment. That is overly vague.

   Dan.

>     role-specific elements for four standard DH groups and the
>     Appendix talks about

---

From: Richard Barnes <[email-masked]>
Date: Thu, 12 Apr 2018 21:38:51 -0400

On Thu, Apr 12, 2018 at 7:52 PM, Dan Harkins <[email-masked]> wrote:

>   There needs to be some demonstration that the key is used "live" in the
> exchange

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
> You're not treating the PAKE as a box that takes a password on one side
> and emits a key on the other side.
>
>
>
> 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.
>
>
>
>>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Apr 2018 12:15:23 +1000

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:
>> 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
> 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.
>