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

Dan Harkins <> Tue, 13 September 2016 23:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0411012B09E for <>; Tue, 13 Sep 2016 16:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HCfMluNYBBy9 for <>; Tue, 13 Sep 2016 16:43:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3C4C312B13A for <>; Tue, 13 Sep 2016 16:43:10 -0700 (PDT)
Received: from thinny.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3672D1FE0244; Tue, 13 Sep 2016 16:43:09 -0700 (PDT)
To: Watson Ladd <>
References: <> <> <> <> <> <> <> <> <> <>
From: Dan Harkins <>
Message-ID: <>
Date: Tue, 13 Sep 2016 16:43:07 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Tue, 13 Sep 2016 23:43:12 -0000

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?

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

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

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