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

[Dan Harkins <[e-mail]>]

On 9/13/16 9:51 AM, Andy Lutomirski wrote:
> 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.

   Yes, that's a good list and let me add that Alice also knows that
b is the private analog to the public key B. Also an important feature.

   If there are any other "properties about offline attacks that the 
protocol
ought to have" that are not already listed in PKEX I'd like to hear about
them. Thank you in advance.

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

   PKEX is, as the intro states, intended to provide trust to public keys
so they can be used in a different exchange that uses "raw" public keys
like TLS and IKEv2.

   Now both TLS and IKEv2 offer security guarantees about the authenticated
state of a successful run of the protocol and these are based, in part, on
the assurances placed in the public keys used in authentication. For 
instance,
that the certificate was not issued to someone who could not prove 
ownership of
the public key.

   So PKEX has to provide, to the best of its ability, the same sorts of
assurances a CA does to public keys in order for it to be able to exchange
public keys with sufficient trust to enable them to be used in protocols 
like
TLS and IKEv2.

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

   Instead of addressing this ridiculous straw man of a protocol let me
refer you to the seminal work of Hugo Krawczyk: "SIGMA: The SIGn-and-MAc
Approach to Authenticated Diffie-Hellman and its Use in the IKE
Protocols." I strongly suggest you read the whole thing very closely but
pay special attention to the "identity mis-binding" attack he describes
against STS "when parties can register public keys without proving knowledge
of the corresponding signature key."

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

   Who cares? The property is not only useful it's critical!

   Dan.