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

[Watson Ladd <[e-mail]>]

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