Re: [Cfrg] PAKE selection process: Maybe we need a modular approach for integrating authentication of human individuals with TLS?

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Fri, 19 July 2019 09:59 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 745B9120179 for <cfrg@ietfa.amsl.com>; Fri, 19 Jul 2019 02:59:05 -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_HELO_NONE=0.001, 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 HGYFfEQtyUfA for <cfrg@ietfa.amsl.com>; Fri, 19 Jul 2019 02:59:02 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 59FD612009C for <cfrg@irtf.org>; Fri, 19 Jul 2019 02:59:02 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id q26so21353720lfc.3 for <cfrg@irtf.org>; Fri, 19 Jul 2019 02:59:02 -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=tD+7DFxM76/HvIaI6gJELgnIjgOFKurHFkjvFXHCD3Y=; b=IyfL+5Lx+Tm5ovPrLraK0CSIospaYEXilQaPhjt8R5om4DJEA8kogsO2at2KLjvYjb Y6aF/UObI4W0OAoTUCRrw8iR8u8memFWn+63MEIbMUX4ix6eeCNKM0y77/007K7tOOiQ 3fIANV9C5ROdFi+Ve+M1V6MDck+swCXlT8Flte1b/oMTkOxdkKvW7Ttx3d40rcx4ho0Y PwbfXQLvTgFDXnwus4/QwiuRq6ay6jKA3org9dkWGyHAeEWA68YxOEK0nXwKhXbAU4Fr abOUyEcttJ7chuHeV1RxC28wQLCcqcFoEAES3mIY2O0uc7sGaCKnwt7gfA0xMDufcnj5 uyyQ==
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=tD+7DFxM76/HvIaI6gJELgnIjgOFKurHFkjvFXHCD3Y=; b=f/yQjRA9mkJIq/TKXgReNWlM9T6nWJqFNvOXpWS8bijcTU/bu8FFw/sQWGx+YFZN+J vB6QnJsEwrf5WKxNnlk1qpVs3l8HKvoA93ByFV7J/fJWDxs5lqNreqX28TGQq0xcoSIY cbagXSFaOPVAoW/gMmA1odfG97ZSZRgSZjiEr89ahsFqBXm9dZB/IjC3FVQskTmkFaOG pZLyFHaQ8e/njb2Z0LDvLDGj09YhS7DrnYU79mxsihf2yxLUhJPVqF2t3reNyw/DM88M f/sMgrtBvYgKJblK2A9PMY3eELJtxRZKCtbwk8WR8rc1ZLVycecQqBXBmKUgXFPYao53 lPIw==
X-Gm-Message-State: APjAAAWz0R05zFrnUpQAL2O6S97wjdyalXuWymwK1N89CLhdCx8aMs8W hAgQTKpc9HpvZb/NOhNrYPjeGYIaQuWhMi7/JEM=
X-Google-Smtp-Source: APXvYqy4ebpPyfFyaSWxDylYwpFP+QT9P3YDW3ptvkPGdsAFCOZvai5J1RiL2JKa5gDH/8t6F+nKO9RsIaVhf485TVA=
X-Received: by 2002:a19:7006:: with SMTP id h6mr23357231lfc.5.1563530340594; Fri, 19 Jul 2019 02:59:00 -0700 (PDT)
MIME-Version: 1.0
References: <VI1PR0501MB2255752B38545BA82261F20383CB0@VI1PR0501MB2255.eurprd05.prod.outlook.com>
In-Reply-To: <VI1PR0501MB2255752B38545BA82261F20383CB0@VI1PR0501MB2255.eurprd05.prod.outlook.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Fri, 19 Jul 2019 11:58:49 +0200
Message-ID: <CAMr0u6=7MNC1amdxKC=W2FsbjW1zWaNuEQ08q9YjGZ6p6kQQVQ@mail.gmail.com>
To: Björn Haase <bjoern.haase@endress.com>
Cc: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000008bf9ae058e05c618"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ILHATw0llCo_7vJQ1hexwSPYZVw>
Subject: Re: [Cfrg] PAKE selection process: Maybe we need a modular approach for integrating authentication of human individuals with TLS?
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: Fri, 19 Jul 2019 09:59:06 -0000

Dear Björn,

Thank you very much!
In my opinion, you’re absolutely right about the importance of these
questions for the process - and, as you may see in the plan of the PAKE
selection process, during the following stages there will be a call for
experts for reviewing the candidate PAKEs regarding such questions as
integrating into TLS and other security protocols, including M2M protocols.

Personally, I believe that your materials will be very helpful for this.
Obviously, it will be important to share your slides on the Stage 4, when
those properties of the nominated PAKEs will be reviewed.

Best regards,
Stanislav

пт, 19 июля 2019 г. в 11:41, Björn Haase <bjoern.haase@endress.com>:

> Hello to all,
>
>
>
> I am writing this mail in order to prepare the future steps regarding PAKE
> on and after the Montreal Conference.
>
>
>
> My personal perception is that among the set of current nominations no
> protocol was proposed that is obviously inadequate. (I personally am
> somewhat sceptic regarding the proof situations for “SPAKE2+EE/BSPAKE”
> and “SPEKE”, but even for these two I don’t see  obvious flaws if
> integrated properly.) My expectation is that regarding the security-topics,
> we might reach consensus in the CFRG community quite easily, once we have
> established a common understanding of the design priorities regarding
> patents, round efficiency, computational efficiency and security-guarantees.
>
>
>
> I believe that the main objections regarding PAKE will come from
> elsewhere: The people that would have to integrate it into larger systems
> like TLS, browsers, OS or password database management modules (such as
> PAM).
>
>
>
> I see the urgent need to standardize a sound PAKE for human user
> authentication and I think that for this purpose we will need to consider
> the concerns and needs of the “system integration” people very seriously.
> Otherwise, we might not be successful with the project of improving
> security and usability.
>
>
>
> When trying to “wear the hat” of these people, I came to the conclusion
> that we might need some kind of a modular system integration approach. I
> have spend quite some time and discussions on this topic. I would
> appreciate your feedback regarding the problem analysis and solution
> approach that I tried to summarize in the slides attached to this mail
>  (also available at https://github.com/BjoernMHaase/fe25519 ).
>
>
>
> Maybe somebody might also spread this link to the TLS working group people
> or discuss the topic of TLS integration of PAKE at the upcoming conference
> in Montreal. (There seems to be an issue with my mail accounts being
> blocked from posting to the TLS mailing list ☹).
>
>
>
> I am looking forward to entering a discussion with you.
>
>
>
> Yours,
>
>
>
> Björn.
>
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
> ------------------------------
> Senior Expert Electronics | TGREH Electronics Hardware
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen |
> Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
> bjoern.haase@endress.com | www.conducta.endress.com
>
> ------------------------------
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta
> Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
> ------------------------------
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
>
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis
> <https://www.de.endress.com/de/cookies-endress+hauser-website> nach.
> ------------------------------
>
>
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities
> other than the intended recipient is prohibited. If you receive this in
> error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or
> an acceptance of a contract offer unless explicitly and conspicuously
> designated or stated as such.
>
>
>