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

Watson Ladd <watsonbladd@gmail.com> Mon, 26 September 2016 19:51 UTC

Return-Path: <watsonbladd@gmail.com>
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 20B5D12B29C for <cfrg@ietfa.amsl.com>; Mon, 26 Sep 2016 12:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uBEBg0QKhxrL for <cfrg@ietfa.amsl.com>; Mon, 26 Sep 2016 12:51:05 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 3DD0E12B249 for <cfrg@irtf.org>; Mon, 26 Sep 2016 12:51:05 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id q42so523635uaq.2 for <cfrg@irtf.org>; Mon, 26 Sep 2016 12:51:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j8th48r3f11zsMRGfC4me4qRWu3pUQq8iatbXDbMC+8=; b=0B8NfTdKPOirAVPTDVoUHajx5LD5/mBgLyUOstdI1r4sZxdkV97PHLmHTjU8Mw7efI Ki0LKwX9R/n7/nkLKZ6zTTFSPsWKHGFJcFg3TV9leF/tigqxK7AQ5jCAIms3t3RFD2Dx MhgtiYcB87Y/F7cIT5fGge4NvzaLQvJa4V+Y1dhHDI2STqljWwsxvfULBaWDVjD0j9eJ Ko1AIci0CD8ex1USRbaR7oW4lzAJTZK+H3yG1xRUUg6Yx2j5SIU3j59gKSxumtQqJoGf o8veR+fLaAIUTCWF0EB29DTK4pFn3ZL4q529C1k5EBAJCJD2kWYJfpW3XJ4HSkttita1 dnew==
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; bh=j8th48r3f11zsMRGfC4me4qRWu3pUQq8iatbXDbMC+8=; b=VryU6DUWrI+LsbRfPf+hhgLpf9Pe30+qmw538CGHvC6SqzeM2o9rVQULsWG8YTsDrw 2KWS7/2id7rzNOEl8JnhKuOehFihddaUvhra70p13uH9FwBQiX6fPScbl1B37cQtv/Gs RPKn+FdKSqkHNO0t+5xmdZUyk0mT+XvwoZ0797IoP96q2J7ZtmcocJkrO5ebYGxNK7xy iC1uQt9wojdWmg+fICv0VWZu00X/fosvBgg/5YwxOLLblzZBVz/AApNWVW6BGydhdB/J MQNGStwyvfhiKbfa7oE+iMYYIAEj7JN0126bBjEBWGtaEJXzEwPONQ4yNVH2hOiQPfqq KkpQ==
X-Gm-Message-State: AA6/9RmJjEg7bL/SQ2ws5prlJBuKP+tWSRc//t5KheqQW9G5cWhVa/B1YO/riRcFQUwafXCP07xhJ1IC2I7agg==
X-Received: by 10.159.53.12 with SMTP id o12mr153465uao.81.1474919464354; Mon, 26 Sep 2016 12:51:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Mon, 26 Sep 2016 12:51:03 -0700 (PDT)
In-Reply-To: <7761a72d-d980-d8a0-dbe3-6f117b852661@lounge.org>
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> <CALCETrX2sf+Ajiiyqj=bm8V2s2jTyYSyURMxfchPXw488rUP2Q@mail.gmail.com> <35b47674-90bc-926c-3a5f-bbe36291ce0e@lounge.org> <CALCETrUyCTRyBcq5nYQEmc7VRmRURQX75uKTxcpQ40q2sXSb8Q@mail.gmail.com> <69fce1b2-d68f-bd70-a969-f36d419ae734@lounge.org> <CACsn0ckPQRAPuUsrQastow2NRr3WXpwxg-YfxXnhHhhvwHs-zg@mail.gmail.com> <7761a72d-d980-d8a0-dbe3-6f117b852661@lounge.org>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 26 Sep 2016 12:51:03 -0700
Message-ID: <CACsn0cnBFTj664EKH3mO=a2e6CFQPRiLFmXp1ALjS7KpC06Aug@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/AXoPp1KUYpzJohVO1ghchnAu8cU>
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: Mon, 26 Sep 2016 19:51:10 -0000

On Tue, Sep 13, 2016 at 4:43 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
>
> On 9/13/16 2:56 PM, Watson Ladd wrote:
>>
>> <Massive exchange everyone has given up on chopped>
>>
>> What assurance do we have that PKEX actually satisfies the security
>> claims claimed for it? Don't you think a conference paper is a better
>> place to put a new protocol then an IRTF mailing list consisting of
>> people almost entirely unqualified to do the sort of analysis you are
>> calling for, and with no proof of security, or even formal security
>> claims put forward?
>
>
>   Well I don't think that most people on this list are entirely
> unqualified to evaluate a PAKE. They may be busy or disinterested
> or turned off by unprofessional bluster concerning "attacks" against
> PKEX but I don't think they're unqualified.
>
>   A conference paper is a decent idea. But I don't think that
> obviates getting CFRG review.
>
>> The commitments do not bind properly: this is obvious.
>
>
>   They bind to the password which is bound to the identities. What
> obvious thing am I missing?

F(x) is 2-1 for elliptic curve keys.
>
>> It is not clear
>> what the KDF is used for, or what properties it requires.
>
>
>   It derives a session key (that can, for instance, be exposed in
> a Reveal query). What properties do you think it needs to have in
> order for the protocol to be secure? Are you bringing up a referencing
> issue (that is, the I-D should point to some NIST FIPS on a KDF?) or
> is this a fundamental issue with the protocol itself?

I am not the one claiming this protocol is secure, nor did I design
it. I would expect you would have some idea what requirements the KDF
must meet. Does it need to be collision resistant, for instance?

>
>> Furthermore,
>> there is no reason to believe that the identities are "trusted":
>> clearly anyone with the shared password can register whatever keys
>> they want with whatever identities they desire.  All that is
>> ostensibly known is that someone who knows the private key and the
>> password has participated in the protocol. It is clear this is an
>> inherent property of an protocol.
>>
>   Each party to the exchange commits to a particular identity when
> it commits to a particular public key. From the point-of-view of the
> protocol I don't see an issue.
>
>   But it is necessary for you to bind the peer's claimed identity to the
> password at provisioning time. As Paul mentioned, Bob has to know the
> identity "Alice" before the protocol begins and therefore he can affix
> the password to "Alice" when provisioned. Only an identity of "Alice"
> is able to exchange a public key protected by the provisioned password.

I think I am less confused now: you are assuming the password is
shared between two endpoints with known identities. In this case there
is no problem.

>
> This is a very good comment. The draft is obviously not explicit on
> this binding and it should be.
>
>   Dan.
>
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.