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

   Dan.