Re: [Cfrg] The SESPAKE protocol and PAKE requirements

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Fri, 22 April 2016 12: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 5965C12DE43 for <cfrg@ietfa.amsl.com>; Fri, 22 Apr 2016 05:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 py4RUxB8rJ2w for <cfrg@ietfa.amsl.com>; Fri, 22 Apr 2016 05:41:12 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 0E1F812DD9D for <cfrg@irtf.org>; Fri, 22 Apr 2016 05:41:12 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id n62so134107716vkb.0 for <cfrg@irtf.org>; Fri, 22 Apr 2016 05:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=AKwT3glVWikjgmLzxwNW6x62TzmTYMIW5uOvXzL7Ckg=; b=Q+O08c9WhB9BuwCnilqcBMIDhDfS849WNq4UO8Luq0mh7yMg0rtulcSfr8pvrlnrf7 uKd5sobBzG9/s1FtXb7neHWOSYsSt9JxlVK0DrGJbndu2hNkc8a5XQKpMRmqoX0lATLi 7Tmi18oR2NCRi+jkJihs1BL7M0sbKp7YQKqOsfGCW92NQ7CW2YF6JIe6FZEhD0O8AMQ/ EvOMMVNRlgYoF/1KXlh5+WqIRGA1TbKW8pQ7SGVtx6aK5hY3lISD+R+zTi/QyBrsMyth DBX9Uf7c3wul6mOxqJcwQ62b1XpWIaYKnddpMZLp/UiMf6ngipC4mb2+f7Z6/xS1k0/G Nh1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=AKwT3glVWikjgmLzxwNW6x62TzmTYMIW5uOvXzL7Ckg=; b=Jo+oNkt5fNGqXZmO9DzZO8OefJo6pH6BBkRTdisAMxsH1BuL8j/4PfwtZkFgXjL6Uv cdVUnJtir/hmG7HI3UiBulIuvLB7WuIuS2/4ZCDQIgjTRmSiGQ5wD7XzW6TNsKmLOypM M3N5HKS7eRmF6EGGXipDBd9QEh1u6v8Ne9d8TA19m5fur+McHy8zzPBSavbz8lqauqM+ YL+h6Od34jBF7Oy7a0FIWKtlV2vDvBmJfPuqfgdV+3ESXmV7BELITIltCjA2nPZfxKRX Rf2qk/RzqwV+GhRl97OgwVJOQHZ2EuCSZ1gnxHyEty1AcEt6gqEILw7CrIy6PNydBzfT NLWA==
X-Gm-Message-State: AOPr4FXzkBVR/78QqaxeW/l2bxFM64LNgCI/D4/a3wzS+JAvlafur190WV5YAwWBD3aYXVo2vwdcnZ4HENKGaw==
MIME-Version: 1.0
X-Received: by 10.176.69.207 with SMTP id u73mr875108uau.135.1461328871092; Fri, 22 Apr 2016 05:41:11 -0700 (PDT)
Received: by 10.31.107.5 with HTTP; Fri, 22 Apr 2016 05:41:11 -0700 (PDT)
In-Reply-To: <38634A9C401D714A92BB13BBA9CCD34F23472FB0@mail-essen-01.secunet.de>
References: <CAMr0u6nu=0H8pi=rEC1i69y1nhGLStvbJUXukUX0uHaVperkSg@mail.gmail.com> <38634A9C401D714A92BB13BBA9CCD34F167B5300@mail-essen-01.secunet.de> <CAMr0u6=eKJyCVQwHpuBLzB2TrrUQrfP8ti9N+Ai108=iS9tkZA@mail.gmail.com> <38634A9C401D714A92BB13BBA9CCD34F167B8267@mail-essen-01.secunet.de> <CAMr0u6m7TD2Nx29q+gFOBEFRswSiSCzXmGoVP_AmZtNhs0vUFw@mail.gmail.com> <CAMr0u6=YnFXRDtXxHuz03g2-Dt74Z1HZ3Pa3GVYOa2_hPFsgrw@mail.gmail.com> <38634A9C401D714A92BB13BBA9CCD34F23472FB0@mail-essen-01.secunet.de>
Date: Fri, 22 Apr 2016 15:41:11 +0300
Message-ID: <CAMr0u6kU2r=xKwAwCW+oCcA=-BDAEb7E2pbx6Df=DDw2-OkGXQ@mail.gmail.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
To: "Schmidt, Jörn-Marc" <Joern-Marc.Schmidt@secunet.com>, "cfrg@irtf.org" <cfrg@irtf.org>, "alexey.melnikov@isode.com" <alexey.melnikov@isode.com>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Mike Hamburg <mike@shiftleft.org>, Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary="94eb2c11c6f242fc4405311224af"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/a5YO3FkdqCeN-XDtMJeqrTYBP6k>
Subject: Re: [Cfrg] The SESPAKE protocol and PAKE requirements
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Fri, 22 Apr 2016 12:41:14 -0000

Good afternoon!


I don't see any major problems with the current version of the draft, just
some proposals.


Maybe it will be helpful to add in Section 4 (after it is stressed that "PAKE
scheme should come with a security proof and also clearly state its
assumptions and used models"), which threats are most relevant (and thus
which threats must be addressed in adversary models considered in secutiy
proofs)? For instance, a threat of distinguishing a key from a random
string and a threat of false authentication.




And one more small misprint: after "However, each proof and model is based
on assumptions" the first letter in "Often" shouldn't be capital.



Best regards,

Stanislav V. Smyshlyaev, Ph.D.,

Head of Information Security Department,

CryptoPro LLC


2016-04-19 11:43 GMT+03:00 Schmidt, Jörn-Marc <
Joern-Marc.Schmidt@secunet.com>:

> Hi Stanislav,
>
> thank you for the feedback. I'm looking forward to your comments.
>
> Best regards,
>
> Jörn
>
> -----Ursprüngliche Nachricht-----
> Von: Stanislav V. Smyshlyaev [mailto:smyshsv@gmail.com]
> Gesendet: Dienstag, 19. April 2016 07:45
> An: Schmidt, Jörn-Marc
> Cc: cfrg@irtf.org; alexey.melnikov@isode.com; Paterson, Kenny; Mike
> Hamburg; Paul Lambert
> Betreff: Re: The SESPAKE protocol and PAKE requirements
>
> Dear Jörn,
> Thank you for an updated version of the draft – we'll revise it one more
> time in a week (a week prior to the deadline marked by Alexey yesterday).
>
> Now I'd like only to mention a small misprint: "Cryptograpic" in reference
> [P1363].
>
> Thank you for your work on the draft.
>
>
> Kindest regards,
> Stanislav
>
>
> 2016-02-25 8:39 GMT+03:00 Stanislav V. Smyshlyaev <smyshsv@gmail.com>:
>
>
>         Dear Jörn,
>         Thank you very much for your comments! SESPAKE will of course work
> with any underlying hash/HMAC/elliptic curve/PBKDF and we’ll prepare a new
> version of our draft which will explicitly stress it.
>         I do not insist on addition of any specific words about primitives
> specification in the requirements draft. In contrary to the question with
> counters handling (our previous discussion), I think it is ok if this issue
> will be addressed by any author of a draft at his own discretion.
>
>         Kindest regards,
>         Stanislav
>
>
>         2016-02-23 9:52 GMT+03:00 Schmidt, Jörn-Marc <
> Joern-Marc.Schmidt@secunet.com>:
>
>
>                 Dear Stanislav,
>
>                 Thank you for your input!
>
>                 >What do you think about defining a policy of algorithm
> usage in PAKE protocols?
>                 >For example, in the current version of SESPAKE RFC draft
> we are based on Russian standards – GOST R 34.11-2012 hash and HMAC, but of
> course the >document that refers only to GOSTs cannot become a CFRG
> document.
>
>                 >Shouldn't we require multi-algorithm support – as in the
> PAKE requirements, as in our SESPAKE?
>
>                 You mean to add a requirement to state which algorithms
> can be used as underlying primitives?
>                 I haven't analyzed SESPAKE in detail - but wouldn't it
> work with any cryptographic hash function?
>                 In case a PAKE requires a special property of the
> underlying hash function/cipher/etc., I think this could be covered with
>                 "R2: A PAKE scheme SHOULD come with a security proof and
> clearly state its assumptions and models." by adding a sentence about
> useful primitives.
>
>                 I personally would leave it up to the designer of the PAKE
> scheme to decide whether the scheme mentions a specific primitive (e.g. is
> specified using AES & SHA2) or leaves it up to the implementer (e.g.
> speaking of block cipher & hash function in an abstract manner). Do you
> think we should push in one direction in the requirements draft?
>
>                 Best regards,
>
>                 Jörn
>
>
>
>
>
>
>
>