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

Watson Ladd <> Mon, 26 September 2016 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20B5D12B29C for <>; Mon, 26 Sep 2016 12:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uBEBg0QKhxrL for <>; Mon, 26 Sep 2016 12:51:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DD0E12B249 for <>; Mon, 26 Sep 2016 12:51:05 -0700 (PDT)
Received: by with SMTP id q42so523635uaq.2 for <>; Mon, 26 Sep 2016 12:51:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id o12mr153465uao.81.1474919464354; Mon, 26 Sep 2016 12:51:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 26 Sep 2016 12:51:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Watson Ladd <>
Date: Mon, 26 Sep 2016 12:51:03 -0700
Message-ID: <>
To: Dan Harkins <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "Adrangi, Farid" <>, "" <>
Subject: Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Sep 2016 19:51:10 -0000

On Tue, Sep 13, 2016 at 4:43 PM, Dan Harkins <> 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".