Re: [Cfrg] PAKE selection process: status after Phase 1 and following steps

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Tue, 09 July 2019 05:41 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 3FDD112023F for <cfrg@ietfa.amsl.com>; Mon, 8 Jul 2019 22:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qYi4p-fboiH1 for <cfrg@ietfa.amsl.com>; Mon, 8 Jul 2019 22:41:30 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 383BC1200F7 for <cfrg@irtf.org>; Mon, 8 Jul 2019 22:41:30 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id c19so6866900lfm.10 for <cfrg@irtf.org>; Mon, 08 Jul 2019 22:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oktpl/sEt33mKyxQKndDHKTNJLBmk6g6TPTQVZQIqxg=; b=uUZ0QLaC1lSV3KUBaK5+n02Kqs1xRRKjOBdz0bk40/mOK2LUz77IpUnrFAM/TSaZli Gheh6jSuFNk+uYeJg2tzX4lxnkJogJfSlkuEMhi37ewRru75WsWOR6S//8/DJ/7x1DDG PT1ckZAx+6RfBddRsuf6rC65AL22IqMELa2d1F6FHB85RdoEKv7DvxiOc1/wZ+riRjvC rzRIHiD/1jr0wpWX8nG2B+UwhW2FrwPEMXBjbu3fbSi0jiRbsfw9yZuq8Ric3Vg+g8f2 MSTM9nqIDsyZDEoH1cHKCGNukVLhix6/IMoR3VB1OyI5EEkkSvN4OAJvPd8eidyrOlQA ne/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oktpl/sEt33mKyxQKndDHKTNJLBmk6g6TPTQVZQIqxg=; b=rSxP5h3XlXdNgTmFBX5RzLljwcwhjmjTQ+2gXNSrXbUhrE8WnRYVd/FV2HTOhyFFDf 1fMHi6ApyLyre7Ilb/dJtO2RUv3RVrN4DKvHy1WyLCQlj626VyE9p1uF5qZF33V5kkO9 C8dwTby+x5JaHdDXoqOo9URKRPh2r1n9BxPnN1cUQU0TE0ILVIuuAoLTkDFF757o9CDH aCrvnIqCbfeI5qoht5Joqm7cM26DQgr38KQhT0WVBpTDxWG5p1+U9iCUcgBTYP3gqOkM x9M6utcXxxkwXiNXQriVshLRJFCsSS0xenZvFlcaPzrUD+yM0k4vsAyYwB9nuUmiy3DN s90A==
X-Gm-Message-State: APjAAAX+OXK6/X83jGwXjyYDVE0xu2xhMhDFiv+ZiizX5t2ZVoNFsORv R44ZiKJpdJ3x4QxIcxAo9Sielow182t9gRiGVDZy1Msg
X-Google-Smtp-Source: APXvYqxQldaM0rQAgy5nHLsAARoT3d+JITjZVwJWUIQxTqSvDerPSeUYg/PcBVnTY+XGdPFfzFY5hUAUE1IcSBq2Qj4=
X-Received: by 2002:ac2:4243:: with SMTP id m3mr10618389lfl.9.1562650888405; Mon, 08 Jul 2019 22:41:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6kxgX+gL7ABxiyDG6KiWdH0qe48R_jL+GHbQNsS0h6yYQ@mail.gmail.com> <CADi0yUPmkDHEkBi5xOVjh_B12tyKHxRkrfQGPs_NWW8nGreLAg@mail.gmail.com> <CADi0yUOWjcHryfeORGXkR-T0PDXCUJVhMoUZLmmA2tiJpL5ndw@mail.gmail.com>
In-Reply-To: <CADi0yUOWjcHryfeORGXkR-T0PDXCUJVhMoUZLmmA2tiJpL5ndw@mail.gmail.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 9 Jul 2019 08:42:52 +0300
Message-ID: <CAMr0u6ke=vPT_ho+hh4D0r=rvuMvs3bbggSjVe2mYw_yQ8utfA@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Cc: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000001c8619058d3903bb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/fGCurF4iuggcFqpIFn7HCyoD554>
Subject: Re: [Cfrg] PAKE selection process: status after Phase 1 and following steps
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Tue, 09 Jul 2019 05:41:34 -0000

Dear Hugo,

Many thanks for such a complete list of responses!
I believe that there's certainly enough information for the reviewers which
will do the following steps of the process.

Best regards,
Stanislav

вт, 9 июл. 2019 г. в 02:31, Hugo Krawczyk <hugo@ee.technion.ac.il>il>:

> Hi Stanislav and CFRG,
>
> Below are responses to the list of requirements from RFC 8125 as well as
> answers to the questions in your email from July 5th as they apply to
> OPAQUE. I have also posted a new version of the OPAQUE draft
> https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-02
>
> From RFC 8125:
>
>    REQ1:  A PAKE scheme MUST clearly state its features regarding
>           balanced/augmented versions.
>
>  OPAQUE is an augmented PAKE (aPAKE) with security against
>  pre-computation attacks.
>
>    REQ2:  A PAKE scheme SHOULD come with a security proof and clearly
>           state its assumptions and models.
>
>  A detailed security analysis is presented in the paper
>  (Eurocrypt'2018): https://eprint.iacr.org/2018/163.pdf
>  Analysis is carried in the Universally Composable model under a
>  stronger security definition that covers pre-computation attacks..
>  The analysis is carried in the random oracle model under the
>           One-More Diffie-Hellman assumption.
>
>    REQ3:  The authors SHOULD show how to protect their PAKE scheme
>           implementation in hostile environments, particularly, how to
>           implement their scheme in constant time to prevent timing
>           attacks.
>
>  OPAQUE combines an Oblivious PRF (OPRF) with any KCI-secure key
>  exchange. The implementation of the latter would follow best
>  implementation practices as relate to that particular protocol.
>  For the OPRF defined in the OPAQUE draft, namely, based on elliptic
>  curves, an operation mapping the password into the curve is needed.
>  This is the most tricky aspect for implementation in terms of choosing
>  the right transform into the curve and avoiding timing attacks.
>  Fortunately, these aspects are now being documented in the CFRG
>  document draft-sullivan-cfrg-voprf.
>
>    REQ4:  If the PAKE scheme is intended to be used with ECC, the
>           authors SHOULD discuss their requirements for a potential
>           mapping or define a mapping to be used with the scheme.
>
>  See response to REQ3.
>
>    REQ5:  The authors of a PAKE scheme MAY discuss its design choice
>           with regard to performance, i.e., its optimization goals.
>
>  The key exchange part of OPAQUE can be chosen depending on different
>  practical criteria such as performance, code availability,
>  compatibility with an existing protocol (e.g., TLS, IKE), etc.
>  The OPRF part can be optimized by the choice of elliptic curve and a
>  corresponding mapping into the curve. The OPAQUE draft is written
>  with multiplicative blinding which improves performance in some cases
>  (as discussed in the draft). Hardening, e.g., via iterated hashing, is
>  offloaded to the client, a significant performance gain for servers in
>  many cases. (See more on these aspects in questions Q13, Q14 and Q17
>  below.)
>
>    REQ6:  The authors of a scheme MAY discuss variations of their scheme
>           that allow the use in special application scenarios.  In
>           particular, techniques that facilitate long-term (public) key
>           agreement are encouraged.
>
>    REQ7:  Authors of a scheme MAY discuss special ideas and solutions on
>           privacy protection of its users.
>
>  The OPAQUE draft explicitly discusses this issue, particularly in the
>  context of TLS 1.3 where different mechanisms may be used to provide
>  protection to user information. These include techniques that do not
>  incur additional messages, e.g., using resumed sessions or a mechanism
>  similar to ESNI draft-ietf-tls-esni, as well as use of TLS 1.3 full
>  handshake augmented with two OPAQUE messages. This is described in the
>  OPAQUE draft and further elaborated in draft-sullivan-tls-opaque.
>
>    REQ8:  The authors MUST follow the IRTF IPR policy
>           <https://irtf.org/ipr>.
>
>  The only patent I know of that covers an element discussed in the
>  OPAQUE draft is IBM's patent on HMQV. Using HMQV with OPAQUE is
>  completely optional. It is described in the draft as the most
>  efficient key-exchange protocol with which OPAQUE can be integrated,
>  but many other protocols (as also described in the draft) can be used.
>  If there is interest in standardizing OPAQUE with HMQV one can check
>  if a free license of the HMQV patent could be provided for such use.
>
> Additional questions from cfrg email (by Stanislav V. Smyshlyaev) on
> 7/5/2019:
>
> Note: Questions are in the same order as in the original email but the
> numbering
>       is mine.
>
>    Q1: How does it meet the "SHOULD" requirements of RFC 8125?
>
>        See above.
>
>    Q2: Does it meet "crypto agility" requirements, not fixing any
> particular
>        primitives and/or parameters?
>
>        OPAQUE is fully modular: It uses any OPRF and any KCI-secure key
>        exchange.
>
>    Q3: What setting is the PAKE suitable for, which applications does it
> have?
>
>        OPAQUE is an asymmetric/augmented PAKE targeted to the client-server
>        setting. The ultimate goal would be to replace password-over-TLS
> with the
>        much more secure OPAQUE. In the first stages of deployment, one
> should
>        target applications that have full control of the user-side ending
> as
>        opposed to relying on generic web-browser environment. Phone-based
> and
>        some enterprise applications seem good candidates for deployment
> (but I
>        am a non-expert in actual deployment of such technology - others
> will
>        know better).
>
>    Q4: Can two communicating parties initiate the key exchange process at
> the
>        same time, or must it always be the case that only one party can
> initiate
>        the process?
>
>        This question is relevant to symmetric PAKE not aPAKE where the
> client is
>        the one to initiate the exchange.
>
>    Q5: Is it suitable to be considered as a standalone scheme?
>
>        The instantiations with SIGMA and HMQV illustrated in the draft are
>        a basis for stand-alone schemes. However, if user's account
> information
>        is to be protected from eavesdroppers then an additional mechanism
> for
>        accomplishing that is needed.
>
>
>    Q6: Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
>
>        Yes! This is one of the attractive properties of OPAQUE. Given its
>        modularity, it can be adapted to work with different key exchange
>        protocols. The OPAQUE draft illustrates this feature for the case
> of
>        TLS 1.3, with a more extensive treatment in
> draft-sullivan-tls-opaque.
>        Integration with IKE should not be too hard, particularly given
> that
>        IKE follows the SIGMA protocol which is well suited for integration.
>
>    Q7: Is there a publicly available security proof? If yes, Are there
> known
>        problems with the proof?
>
>        Yes. See answer to REQ2 above. No known problems with the proof.
>        Two observations for the expert: First, as noted in the paper, the
>        2-message case (without explicit client authentication) requires a
> slight
>        relaxation of the UC SaPAKE functionality (without diminishing
> security
>        against pre-computation attacks). Second, as noted in the paper
> using
>        multiplicative blinding raises some technical issues which we are
> still
>        studying (paper should be available shortly). The current OPAQUE
> draft
>        obviates these technicalities by including the value vU under the
>  OPRF
>        hash. One aspect of the analysis that can be improved is that the
> current
>        model assumes static corruptions. Moving away from the random oracle
>        model (with its known limitations when implementing it with actual
> hash
>        functions) would be good, but improbable at this time.
>
>        The OPAQUE draft includes a discussion (under security
> consideratrions)
>        about the applicability to OPAQUE of the Brown and Gallant [BG04]
> and
>        Cheon [Cheon06] attacks on the one-more DH assumption. The
> conclusion is
>        that this attack is not practical in the OPAQUE setting.
>
>    Q8: Is the considered security model relevant for all applications that
> PAKE
>        is intended for (e.g., if a PAKE is to be used in TLS Handshake, it
> is
>        important that the TLS adversary model is considered for the PAKE)?
>
>        OPAQUE assumes composition with a secure key-exchange protocol
> which is
>        resistant to KCI attacks. Any such protocol can be used with
> OPAQUE.
>        TLS 1.3 offers such security as analyzed in different papers and by
>        different methods.  As always, the security of actually deployed
>        protocols is more complex than their underlying theoretical design
> and
>        analysis. But as long as one uses and implements correctly the OPRF
> part
>        of OPAQUE, if native TLS 1.3 mechanisms are used for the rest of the
>        protocol then OPAQUE would be no less secure than TLS (and much more
>        secure in comparison to the password-over-TLS application).
>
>    Q9: Does it allow to be sure in sufficient level of security for common
>        values of password lengths?
>
>        Password length makes no difference to the security analysis of
> OPAQUE.
>        Obviously, a low entropy password facilitates only and offline
> attacks.
>
>    Q10: Does its security depend on any nontrivial implementation
> properties?
>         Are they clearly stated in the document?
>
> Note that the OPAQUE draft is not intended as a full detailed
> specification but as a general description that explains the different
> components of the protocol, their interaction, and functionality.
> A precise specification from which interoperable implementations can
> developed will be produced when consensus is reached into the best way
> to instantiate OPAQUE pieces. Yet, the draft already highlights issues
> of implementation; it also refers to draft-irtf-cfrg-hash-to-curve and
>         draft-sullivan-cfrg-voprf for the more subtle issues surrounding
> OPRF
>         implementation.
>
>    Q11: Does the PAKE have precomputation security (for augmented PAKEs)?
>
>         Yes.
>
>    Q12: Does the PAKE relies on the assumption of a trusted setup
>
>         No. It doesn't.
>
>    Q13: What's with the "round efficiency" of the PAKE?
>
>         I am not sure I understand your definition of "round". I prefer to
> talk
> in terms of number of messages (i.e., flows or flights in TLS
> terminology). OPAQUE costs two messages for computing the OPRF and any
> number of messages as defined for the key exchange in use. In many
> cases, e.g., SIGMA, HMQV, these messages can be parallelized resulting
> in 2 or 3 messages for the whole protocol (3 is always needed if
> explicit client authentication is required). Protecting user account
> information can add up to two messages depending the setting.
>
>    Q14: How many operations of each type (scalar multiplications,
> inversions in
>         finite fields, hash calculations etc.) are made by each side?
>
> From the OPAQUE draft:
> The computational cost of OPAQUE is determined by the cost of the OPRF,
> the cost of a regular Diffie-Hellman exchange, and the cost of
> authenticating such exchange. In our elliptic-curve implementation of
> the OPRF, the cost for the client is two exponentiations (one or two of
> which can be fixed base!) and one hashing-into-curve operation;
> for the server, it is just one exponentiation. The cost of a DH exchange
> is as usual two exponentiations per party (one of which is fixed-base).
> Finally, the cost of authentication per party depends on the specific KE
> protocol: it is just 1/6 of an exponentiation with HMQV and it is one
> signature in the case of SIGMA and TLS 1.3.  These instantiations
> preserve the number of messages (two or three) in the underlying KE
> protocol except in one of the TLS instantiations where user privacy
> requires an additional round trip (this can be saved if using a
> mechanism similar to the proposed ESNI extension {{I-D.ietf-tls-esni}}).
>
>    Q15: Which recommendations for secure usage can be given?
>
>         Not sure what this refers to. If the above answers do not address
> this,
> please let me know.
>
>    Q16: Is it defined how the explicit key confirmation is performed/must
> be
> performed externally? Are there clear statements whether this procedure
> is optional or mandatory?
>
>         Performing key confirmation is a design choice that may depend on
> the
> chosen key exchange protocol and desired properties. The security of
> OPAQUE as an aPAKE does not depend on a key confirmation step (except
> if one re-defines aPAKE to necessarily include such step). All the
> instantiations discussed in the draft (HMQV, SIGMA, TLS 1.3) already
> provide or can be augmented to provide key confirmation.
>
>    Q17: Can any recommendations on using iterated hashing (e.g., with
> Scrypt)
>         with the PAKE be given?
>
> The OPAQUE draft touches on this issue (sections 2.1 and 3.4). The
> hardening operations are performed by the client. This has the advantage
> of freeing busy servers from doing this purposely-expensive operation.
> While most clients would have no difficulty in running such hardening
> operations, there may be legacy clients whose limited computational
> power may limit their ability to run a large number of iterations (or
> whatever operations the hardening scheme requires).
>
>    Q18: Can any recommendations to avoid a user enumeration attack be
> given?
>
> Yes. The OPAQUE draft (Section 5) discusses this issue and mitigation
> measures in quite detail.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>