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

Andy Lutomirski <luto@amacapital.net> Tue, 13 September 2016 16:52 UTC

Return-Path: <luto@amacapital.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27AD12B39A for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 09:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOyHlvIpkYHe for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 09:52:05 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67F512B1C5 for <cfrg@irtf.org>; Tue, 13 Sep 2016 09:52:04 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id 16so167799158vko.2 for <cfrg@irtf.org>; Tue, 13 Sep 2016 09:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Jrpe6A5YrHyEweOeGv+c5pmaWJxNKPsxXx2gGpKNu7I=; b=wN7cTVixlDOYVRDxKhsktx2jbERHHczfGYIZpk7uXG01+66glEpRAUyH53hmYeN8Zm kU2UlRCGI4lwuLxRp+Aaa5DP8WC0rTh1oHhJg9UCned8AJidtsglUB62rBT9oq7pUwEe vXx9j/XGV89lU/VXCIPrtxBNLtbZf+Luq2jfeEJsT/85I65E/gK/dwWFBVODH1hgIm21 e4MmyW4lK9p6lJo4v912m1Al+hnPv1Jtp2l+n6SkHRfxVg9YyfuiYM2ACLPAbMp9qpNI Bhy1E9BYrRcg1ygX8ddakUpaCxEbmZ1S7BAZhoHIoX+qxiWzhcktDvzjj8Sw2P96PodL 59hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Jrpe6A5YrHyEweOeGv+c5pmaWJxNKPsxXx2gGpKNu7I=; b=AHHssJIeiLY5mXmKgN/X9AijYKCHT3g9kKvj92Zi1uhNeP82ecBrVJUH99X3K7O29p J14ezjBRDNbYQoD90EGKFoqk4fcBmC7rcKamh77TNsfHQg+E/SismOGMPxVm/al19KPK fW+QPXhSkpWoi87+q3dwO39/K+vRUtIcja0MlbeqBRAUNkxd77Ummly67vt6HGPoRhlt mUykCnEjxE0Bu1thb9xdoaGHXpvnBAUIEPb45FVN0tUJLz/7hYQQbiI6/nmpFo5kxcdG WSGMIOpHS7uDuDi+1UIVo4NCEa1/ruNqy4DZTppiXO55D9gRP+7atn65+3ff9OMvoRm/ sDbQ==
X-Gm-Message-State: AE9vXwM+5nu2znsPPFiYbuy0lJ488kDph7X5sUf8h7RsZcNSdBR2XnhYtaJ6ztkJ4uf3z0UMa4PLNNpCtVOywWIF
X-Received: by 10.31.99.130 with SMTP id x124mr1829219vkb.76.1473785523929; Tue, 13 Sep 2016 09:52:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.51.23 with HTTP; Tue, 13 Sep 2016 09:51:43 -0700 (PDT)
In-Reply-To: <D3FD4294.A005A%paul@marvell.com>
References: <D3FC35C1.9FC94%paul@marvell.com> <56878156-5fdf-9541-f9e2-882ab54a1632@lounge.org> <D3FC63E7.9FF36%paul@marvell.com> <8c36f26a-59b4-e483-c1e5-12a083f4b0b0@lounge.org> <D3FD4294.A005A%paul@marvell.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 13 Sep 2016 09:51:43 -0700
Message-ID: <CALCETrX2sf+Ajiiyqj=bm8V2s2jTyYSyURMxfchPXw488rUP2Q@mail.gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/hHgWP6DLoatuORUySUWQvjSVVlA>
Cc: "Adrangi, Farid" <farid.adrangi@intel.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 16:52:07 -0000

On Tue, Sep 13, 2016 at 7:36 AM, Paul Lambert <paul@marvell.com> 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?