Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.txt

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Wed, 01 November 2017 05:45 UTC

Return-Path: <smyshsv@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 5420213FCC2 for <cfrg@ietfa.amsl.com>; Tue, 31 Oct 2017 22:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 A9iF3Ae3fPwi for <cfrg@ietfa.amsl.com>; Tue, 31 Oct 2017 22:45:56 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 F283613FCCD for <cfrg@irtf.org>; Tue, 31 Oct 2017 22:45:55 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id z28so1437205qtz.13 for <cfrg@irtf.org>; Tue, 31 Oct 2017 22:45:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t1qCFwfKR6ylAzls4Zrcbs/sJh1vbklt4U6Gl+Uskyw=; b=NLed7JualbdVIdgUcbAbs5BdSnNZ4m15MlEZ1HuSi+upz47xVNGMDvf5rzctfW2ybZ CZw/LCJxdu9NwDgBIxVjrYREZFHMnjwClvzJlpKfzzJg8i3KMbTV1qF9AwJHkEA6lVwA lg2JgGZLInELNPaHkXxuCyYNsBEbWQyycxNsFHmMQ8/Q+N7Kdz1EbXNMw0sF3bNrDj4K QyO3JQ2RXQpuEaatWiiCKjkoOVz31ZcULDy5XLx0L955x2elGFOa11kvOf+uc7V2h8d1 Cd04sCPsGBZ1gkb4nn+ZqCuBlwz7ZzjjSVhwQKoXc8ErrVu9VUtPVez4PdmQHORKjT78 ECcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t1qCFwfKR6ylAzls4Zrcbs/sJh1vbklt4U6Gl+Uskyw=; b=NkUbjnCxg2Jh8MAoRApWN04ahNtPM7U7gF5WoZRX7wJ+tNrBkWNNDUda32To9E3ic3 gAyQRS+CE5nL3PpqTEffkO7e7QAYLYSpyznCqe9v2q2hz6e7cSG82hDt5nDpEL+JG7e7 b0HUX37pUhdRqrKMVvTZqshwwR0DUS1EQ5iwnCIDTlbTaJE/8+honO+jVNj32fLjTnC7 g7xJTqXWwU/Jxxn2MrrQia1YTqJ1qIL36W89fVx4B8oSiMCCDOvUzCQGN2B4sLTgeKAy YU441dXCGJRhEe8sP+xn1UkDAdluXJb+x1vgYDPEylLCKUfrze5jnZJKVhrJdY9271WX TNyA==
X-Gm-Message-State: AMCzsaW3UyZW0Zcyokymf8lgeTnxcsArKMC6jDrwu7vsHVSHNbLGXjYM h1zAAjmzbqN6eq84OEA9+xh4lkczZzNcbYgKJ8rCCg==
X-Google-Smtp-Source: ABhQp+SH3HYydtFBpkXjhSga4fOUV0EfvTegQ0VwY4QfLaygY5w2bNKoZmnW4LyqCUD5p10EmKg9pMEYOxXFvEg6NJM=
X-Received: by 10.237.36.225 with SMTP id u30mr6437403qtc.13.1509515155101; Tue, 31 Oct 2017 22:45:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.142.67 with HTTP; Tue, 31 Oct 2017 22:45:54 -0700 (PDT)
In-Reply-To: <502ff23e-72d3-88ce-7f03-92e6aecde717@lounge.org>
References: <148341961917.21855.12696727221580481006.idtracker@ietfa.amsl.com> <502ff23e-72d3-88ce-7f03-92e6aecde717@lounge.org>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Wed, 1 Nov 2017 08:45:54 +0300
Message-ID: <CAMr0u6mF-yY1eYHj6rVctMNXWZqJzv8gSM28XS3ZJ6+kpq8DaA@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="001a11410c9e9a5bea055ce5629e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/wQ1kkrSgKgR3bFWTYagy8gnAkeY>
Subject: Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Wed, 01 Nov 2017 05:45:59 -0000

Dear Dan,

During the analysis of Wi-Fi DPP proposal, I've had a chance to look closer
at your draft (and many thanks to Liliya Ahmetzyanova for her comments),
draft-harkins-pkex-04 <https://tools.ietf.org/html/draft-harkins-pkex-04>.

The document is in a pretty good state, in my opinion. Also I don't see any
critical problems in the protocol or it's description.

However, there are several recommendations that you may find useful.

1. It would be better to indicate point G explicitly (as it is already done
for P_I and P_R). Also it would be better to generate new G by the same
method as described in your document or in [LMSS].
2. It seems useful to add checks of X' and Y' for not being equal to the
point at infinity.
3. We strongly recommend to describe explicitly possible countermeasures
against online brute force attack. For example, they can consist of using
counters (so it should be stated when to change it, limitations of their
values and what should peers do when this limits are reached, see
([RFC8125] and [RFC8133]).
4. The PKEX protocol translates code into an elliptic curve point in the
following way. The code is hashed within other parameters and the hash
value is used as a scalar which an elliptic curve point is multiplied by.
There exists small but still non-null probability that this hash value
turns to zero modulo q, where q is the order of the used elliptic curve
point group. If that happens, an ephemeral key is not masked and the
overall security of the PKEX protocol is violated. It seems useful to add
checks here and introduce some algorithm that changes zero hash value to a
nonzero value in a deterministic way.
5. Maybe you consider reasonable to think about using an additional value
"salt" to randomize the masking points Q_I and Q_R for different sessions
by adding one more argument for hash function. The salt value may be chosen
by the Initiator and transferred together with the point M.

References:
[LMSS]: Lochter, M., Merkle, J., Schmidt, J-M., Schutze, T.: Requirements
for Standard Elliptic Curves. Cryptology ePrint Archive, Report 2014/832.
[RFC8133]: S. Smyshlyaev (Ed.), E. Alekseev, I. Oshkin, V. Popov, The
Security Evaluated Standardized Password-Authenticated Key Exchange
(SESPAKE) Protocol. RFC 8133.
[RFC8125]: Schmidt, J.-M.: Requirements for Password-Authenticated Key
Agreement (PAKE) Schemes. RFC 8125.


Best regards,
Stanislav Smyshlyaev


2017-01-03 8:07 GMT+03:00 Dan Harkins <dharkins@lounge.org>rg>:

>
>   New version of the PKEX protocol... changes include cleaning up of how
> proof-of-possession is accomplished and some new role-specific (SPAKE2)
> elements for some popular FFC groups from RFC 3256.
>
>   This protocol allows for the establishment of trust in "raw" public keys
> to be used, subsequently, in protocols like IPsec or TLS.
>
>   Comments are solicited!
>
>   regards,
>
>   Dan.
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-harkins-pkex-03.txt
> Date: Mon, 02 Jan 2017 21:00:19 -0800
> From: internet-drafts@ietf.org
> To: Dan Harkins <dharkins@lounge.org> <dharkins@lounge.org>
>
> A new version of I-D, draft-harkins-pkex-03.txt
> has been successfully submitted by Dan Harkins and posted to the
> IETF repository.
>
> Name:		draft-harkins-pkex
> Revision:	03
> Title:		Public Key Exchange
> Document date:	2017-01-02
> Group:		Individual Submission
> Pages:		30
> URL:            https://www.ietf.org/internet-drafts/draft-harkins-pkex-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-harkins-pkex/
> Htmlized:       https://tools.ietf.org/html/draft-harkins-pkex-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-harkins-pkex-03
>
> Abstract:
>    This memo describes a password-authenticated protocol to allow two
>    devices to exchange "raw" (uncertified) public keys and establish
>    trust that the keys belong to their respective identities.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>