Re: [Cfrg] Proposed PAKE Selection Process // Integration in TLS ?

"Björn Haase" <> Wed, 19 June 2019 09:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5C5A120456 for <>; Wed, 19 Jun 2019 02:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CNk-jmId72a2 for <>; Wed, 19 Jun 2019 02:21:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EB1812045B for <>; Wed, 19 Jun 2019 02:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dbaedf251592; t=1560936107; bh=P12+X5lQam6KFJ7Kpjr8Ajt0TIIgos3FtZ8fVtDorfI=; h=X-UI-Sender-Class:From:To:Subject:Date; b=HfOifgr3YmqgwGzPgF4lNwNxP+iP9DX2vZkMOmBHP/iFBGTMLQ+m+kkl1R0Am5ph2 M9rBIiYHderuZAUJYSlLugsulVxFuCC31sOWLsJC+/lzvJVjUEbESOHkqWQHNy1CFJ wZ+ouHyCOjE9x0HcZ6sSRPT9BPc1Ice1OSe5a/P8=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by (3c-app-webde-bs23.server.lan []) (via HTTP); Wed, 19 Jun 2019 11:21:46 +0200
MIME-Version: 1.0
Message-ID: <trinity-24ffcea8-2b91-42e5-9546-f533a825e019-1560936106868@3c-app-webde-bs23>
From: =?UTF-8?Q?=22Bj=C3=B6rn_Haase=22?= <>
To: CFRG <>
Content-Type: text/plain; charset=UTF-8
Date: Wed, 19 Jun 2019 11:21:46 +0200
Importance: normal
Sensitivity: Normal
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-Provags-ID: V03:K1:A8/fR7qVlfnAOiXVW3A9OXlG+JeYi0NNyY1xe3L2K11cA6FdIo3OtxzphMdBdm1P3CK4u WenH/AKHYFaANmak89hH3HCqyu3Suz2ITYbM/rdUZGOiZZYcZwffUsUJIwKH3qOlpvMudP88siAt yjSw4g1zTSQqaBea6ebCBfwrvg8yZzYP5EOcztdFVVmATxxAoedTzhJbe/yH/yGZ6aBVvWB3Iw0I pykEsvyE762GCXLzXps4/EyGjXvvH6KCO3DLsa1Q5mkSGnQYMve0o3RHxFyGyj1+enAT1GAlrcd8 ms=
X-UI-Out-Filterresults: notjunk:1;V03:K0:1dGWhW48efI=:l/wefNcTjbpJOme8aDoSaa 0pnlRzLBebh9uO70/Gj627xc6iidrlhaYr/PFiAg8vxWWVl7I1oskjH0LDbi1nWH/obxWR1Q/ /l9rNj8kWmGc7WlxEKE4kyDTa9EPqfZdXX9aOdkA8vaisDi72c91n+qSdn/1H08d6dhGxPgJB /79uKCKFQS7znVZcvcm1ZgoYWHVif8Dx8WUgtxq1Yk1auwpVJTweBMiZ7Vwu19aDgR8ngLXnj fScPciEsXUClAFVennoTQ1giXSC0SmfBowtjEVcdG+4JWlN/wbUkgUrcbcVifX9pihhQ/Z6Od wFQ0dFvmuYqNI+bdnI/PSCWk3H+OcJ1boE71nCLdmrfnO/P94XvfaUIE/Ul2zIKO3zAneE9UR 9snB+Jua1WmyqJOc3hlW/e2gN8Us9m3llhdM8gb6cB8qH0/1iRXWuHKEMMSVfsnwMS87IaMPf 6yi6TSlX92+2qf+RhjgHDnEoRrkKVyFtjFofoipvms0MZZcOBGM8WrH5JEIE585+J2ZO5Anro QXaxARK5je7o8v1FULtYwiLwQC06QSbzcecBfAXgrWM/0FM2N/br2uNo3dPVo0D4NCLSyALmF B1RfXKkmOjLGjTvHE8Vtqcr4r+OmFTxo0YN5pnQ/L7Ko05eHsE9x+nOQ==
Archived-At: <>
Subject: Re: [Cfrg] Proposed PAKE Selection Process // Integration in TLS ?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2019 09:21:57 -0000

Dear Eric,

thank you for your feedback! I do agree with and understand your points.

I am having several questions/remarks which I would like to address in separate threats, starting with the possibly most controversial side-aspects to consider for TLS integration.

> Eric Crocket wrote:
>1. We would like to see the standardization of both a standalone scheme and its integration into TLS, similar to SRP (RFCs 2945 and 5054) or OPAQUE

I fully agree with you and also would also like to see PAKE integrated as a component in TLS. The important aspect to consider, when doing this, IMO will be that we are then integrating components into the TLS stack which today mostly are assigned to the "application layer" (which often should be expected not to consider security adequately). 

E.g. after a successful TLS-managed login the application on the server will need to know which user is just logged-in, e.g. in order to find out which authorization rights to attribute to the current session.This means that the interface to the TLS system would become somewhat more powerful and complex, by providing interfaces regarding user accounts.

Also for some use-cases, the application will have the need to request a re-authentication of a HMI user: Consider, e.g. the use-case of a "Do you really want to trigger the self-destruction functionality? Please re-enter the password" mask.

I.e. for the use-case that you did sketch (similar to my use-case U2)  I'd see the need for interfaces between the TLS system and the "application layer" for

- Querying which user is logged in and optionally mange authorization rights
- Arranging for a re-authentication upon application request, possibly with another account (similar to a "su" shell command on unix systems).
- Optionally: Managing user accounts (e.g. Password changes, changes of authorizations).

The key question that makes above components mandatory (IMO) is: Does the application layer need to consider user accounts with different authorization levels? 

In the settings that I have in mind (my use case U2) the answer is: Definitely "yes, we need to deal with the complexity of user authorization levels."
How is the situation in your AWS use-cases?

IMO the aspect of a possibly more complex TLS interface will generate a lot of discussions, but this is definitely manageable. We have been doing this specifically in our proprietary TLS-like security stack for our industrial HMI service app (E+H SmarBlue). The advantage of integrating the account management in our security/networking stack is that this way, we were able to clearly modularize the software into a security-submodule and an application-module.

I expect a lot of discussions, but the overall advantages also regarding usability on the HMI interface and the ease-of use for the security configuration together with the improved security would be definitely worth the effort IMO!

Note that all of this complexity does not show up for the use case U1 (PAKE as replacement for PSK) from my earlier mail, since distinction between several authorization levels was not relevant.