Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt

[Andy Lutomirski <[e-mail]>]

On Tue, Sep 13, 2016 at 7:36 AM, Paul Lambert <[e-mail]> wrote:
>
> With enough tries … PKEX 3.0 or PKEX n.0 could be deemed secure. Including
> the validated exchange of public keys in a PAKE exchange is a very
> interesting mechanism. Usage constraints of such a protocol still may make
> it inappropriate for particular applications.

Can we take a step back and ponder *why* a protocol that exchanges
public keys and proves possession of the corresponding private keys is
useful?

Here's roughly what PKEX tries to achieve (I think):  Alice and Bob
each know a password, and Alice and Bob are assumed to be the only
parties that know that password.  Alice can run PKEX and, if the
protocol succeeds, she knows that (1) a public key B, (2) that Bob
claims that the holder of the private key b is Bob and (3) that Bob
actually has the ability to perform private key operations using b.
Bob learns the same things about Alice and her keys.  There are whole
bunch of properties about offline attack that the protocol ought to
have.

For the purpose of pairing two devices that intend to communicate
using public-key crypto, property (1) is obviously critical.  In my
mind, property (2) should be sufficient.  I'm asking why property (3)
is useful.

Here's an example of a bad protocol where you need property (3).
Suppose that Bob writes a message that says "Please send me $100" and
signs it using b.  Alice receives that message with appropriate
assurances from someone she trusts that she should pay $100.  She
further learns via an *unauthenticated* channel that the money should
go to Bob.  She looks up Bob's public key B, checks the signature,
decides that only Bob could have sent the message, and sends Bob $100.

This protocol requires property (3).  But it's insecure in general
anyway because digital signatures don't provide the guarantee that
Alice is relying on: in many digital signature protocols, Charlie can
take a signed message and generate a brand new key pair that appears
to have also signed that message.

But this protocol is just silly and shouldn't need property (3) at
all.  Bob should sign the message "Pay me, Bob, $100 to this account"
and Alice should look up the key that Bob says is safe to use to
identify him (property (2)) and check the signature.  Problem solved
(and it's now using digital signatures correctly, too).

So what is DPP doing that makes property (3) useful in pairing?