Re: [TLS] External PSK design team // Scope for "Low-entropy PSK" applications

Björn Haase <bjoern.m.haase@web.de> Wed, 22 January 2020 20:30 UTC

Return-Path: <bjoern.m.haase@web.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9C120131 for <tls@ietfa.amsl.com>; Wed, 22 Jan 2020 12:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de
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 VGCGgPi4mDtm for <tls@ietfa.amsl.com>; Wed, 22 Jan 2020 12:30:33 -0800 (PST)
Received: from mout.web.de (mout.web.de [212.227.17.11]) (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 55F14120130 for <tls@ietf.org>; Wed, 22 Jan 2020 12:30:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1579725029; bh=fFRQrpbYBKi7GK7l4DdG2VWQeYBT67bqdSIk09+BOL8=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=MdnZxtnofzJZradf2iJLW4O+R09T8uv2tLD4xYlc0Op6FxZtSC8wiAv/HNA6aUJ3T uLgKg+vzBu7I771U/Dpo3ecuqlZnYaw0I7P9lA0ZfizabiFcb1q2eSvx7zOiQENwaS 45UsO0MXYbQ1Xw1wrTyg+DX8uLUr7eCa/f55TyoU=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [192.168.2.161] ([188.110.251.139]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MYf78-1j88Gc44AM-00VPyR for <tls@ietf.org>; Wed, 22 Jan 2020 21:30:29 +0100
To: tls@ietf.org
References: <VI1PR05MB6509A9CD4D51A2E7D4BDD200830D0@VI1PR05MB6509.eurprd05.prod.outlook.com> <96B7FA74-983E-4CB5-AD13-D9982A86EAC7@sn3rd.com>
From: =?UTF-8?Q?Bj=c3=b6rn_Haase?= <bjoern.m.haase@web.de>
Message-ID: <7bd2a441-7a17-c531-a45e-f8bf05021cdf@web.de>
Date: Wed, 22 Jan 2020 21:30:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <96B7FA74-983E-4CB5-AD13-D9982A86EAC7@sn3rd.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:wvNzQ54e/gaXiTLjgvelDPL1/8qZCo5d29V6UzMzpMh9yeDcXET xSwWQluFnBuKMZJQt8aZJ2Im3hvvW+I2lihZoR80CVa2rISjJdg2FDyJqdg2v1t8wQmT0/D c2c1e5EOqXxoGxSgNDTGwDKxyyi5NlmwZpFA/gYgQdzHSX7L/O33Qe3owIko3gA6z7GP7kB h76rQ3Cl8iQv1TtWe+WBg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:+TcZ7AE7p4A=:GSxPu3UOaiFZ7XrWiYjW0b fHM6SlqHgYuqXtLdKh5HOl1sFPQS64aiop+YDQGsfSLui+f1ZeYTIannJZX2uTriZFrpaGxnQ GsIl2qKNF42BNLLRxTIQVHj6dxHFy/N5sgUNxFKHT1FieoBxvgeBsVd3z89VWyrFv7caBrtXF qqp/q5xbAQlgQHXd0PoplvoXhfWVLsw+WZwdt/XZ/geE4AOlMJuZgQ6xUKicWZwePUosdfkmN BtE8WUyQ9/vQkEpOgRqCwv5YZO95NiThnf0ksQih0woY4680A+BYaH+qWsfeFyxL5QtKxi/+v FulYkUGdi2GZoyXcvBoCffwqncTSr/RFeYj03ChFbYXgmgMn+0aj6YXpb9ci6er1flj5CecM1 A4aMwSIcZwmNWpgERKUjUE4KE/32+tVJGr7k5xFEF0KNTJlIuyDVhLYZRdxpY5KpZmql9XNVG /lOYDoNxQ4nahN9mg3LQq6h2ipUjrtMA2M80n3RpHAuYHhHxQKVHVV501mgG1b71wciQGn6Dc alftmUeWavUYFz9jijQrFt1bT7s29piv4TwH5Jzb4zow7Pq8U9E7r2rqmIYnT0sm2O09tsj16 GctfwT4CQGc1RgRUZF52ALNcFzaacKbxHcr2K5D57MF0bzTFCoFFnBgENFDRkvL8Bn8Ze0G0H +VSouFn4tK4aHQ1LrmRn0a2R1qP8LP9ulIphmMJvqGPuRPeyFc93eHhBwmm1+3rgJY1fPqYji h+QNU6bkE4iytDOjhhbuPHQCX/imTFE0QMtfBEcpgvSUOPQuyLduNEvFkZCaWxaApwqr0/MOv zb70hlDoR510ZBkMBboiVCzsKBnhMwXrfWZUUaNyBLbFF3XvWBvb9lbolaM0BA2J+5fdQiTBw HYZzPbDls780eDpU67AjxoWvXJ6DixWSePLxiArGKVJxJOOF9GI4GsPjayzr2oCKPKIEiWLiz xtbh5LKaF8F0+FOeeqiUP/eXxYHhTqGGCIsmXc6SvJhFRVFmk9nr/VoSGD/Q4EJ1KIIiDqXGU UknRBY71H2uay38J6ceZGUdHotMmQQ5Hy4s+SRyyF/63PfOd9JjHV5hqjmYsiffTrZg0x8yht MRQ6evpnuB7dkbLfzrNkhZ1dKe44XHivWWWiw5WF7c8aW0zZRTNsv1+3sACLEtI62vibEocPg HB68OOHeibbf3+XNBrzDUnEugHtPZrGWuZodUpDySYdrLShpVspYN5alI1qwrRkUxydmyeD8u 25AxFxe7ZsobL/spp
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/psHcrYxJebZPBad5qoSgdvPT6EY>
Subject: Re: [TLS] External PSK design team // Scope for "Low-entropy PSK" applications
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 20:30:36 -0000

Thank's for the clearification.

Having a document clearly specifying how external PSK could be securely
used is a good idea.

I did not aim at blocking useful work with new features! The root of my
question and my motivation is, that just today, I have received a draft
of an industrial protocol specification that suggests the use of PSK
mechanisms in conjunction with passwords :-(. Even if the spec. says,
"you should use at least 16 characters digits and special characters,
randomly chosen", I am having a quite clear expectation on what the
actual real-world users will be doing ...

The first step would be to clearly specifying and documenting the secure
use of PSK, e.g. by pointing out that using passwords as PSK this is
*not* a good idea. (I think that there is already somewhere
documentation on this, but something *really* explicit is certainly
helpful.)

Personally, I'd be willing to spend time and effort for preparing and
helping with the second step: *Resolving* the issue of accidental
mis-use of PSK, by integrating a PAKE into TLS. My ambition would be
that the resulting PAKE / "Low-Entropy PSK" mechanism is so efficient
and easy to use and integrate, that no overhead in comparison to
conventional Diffie-Hellmann is perceiveable. If everything ends up
nicely, one might even consider replacing the PSK mechanism in favor of
a more misuse resistant PAKE approach (maybe some day in the far far
future :-)).

Yours,

Björn

Am 22.01.2020 um 18:23 schrieb Sean Turner:
> Hit Björn,
>
> This DT grew out of discussions related to draft-ietf-tls-external-psk-importer.  Ben (our AD) suggested that we start a DT to have a standalone document to describe considerations for how to USE the PSKs to avoid various attacks.  The chairs would prefer to keep this DT focused on that particular topic and not expand it to “low-entropy PSK”.
>
> As the “low-entropy PSK” problem seems wrapped up with the CFRG’s PAKE selection, we think that it would be better addressed after that decision has been taken.  We are not saying you or anyone else cannot work on this topic, but we do not think that we should not consider standing up a DT until the decision has been taken.
>
> Chris, Joe, and Sean
>
>> On Jan 21, 2020, at 11:03, Björn Haase <bjoern.haase@endress.com> wrote:
>>
>> A question regarding the scope of the PSK design team:
>>
>> In my opinion there is definitely a need for a secure solution for “low-entropy PSK” approaches. It seems that this topic does not seem to be within the scope that Sethi Mohit did have in mind.
>> If this topic would be out of the scope of the PSK design team, would there be another team working on this “Low-entropy PSK” aspect?
>>
>> Yours,
>>
>> Björn
>>
>> Von: Eric Rescorla <ekr@rtfm.com>
>> Gesendet: Dienstag, 21. Januar 2020 15:52
>> An: Jonathan Hoyland <jonathan.hoyland@gmail.com>
>> Cc: Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org>rg>; Björn Haase <bjoern.haase@endress.com>om>; TLS List <tls@ietf.org>
>> Betreff: Re: [TLS] External PSK design team
>>
>> I am willing to contribute.
>>
>> -Ekr
>>
>>
>> On Tue, Jan 21, 2020 at 2:50 AM Jonathan Hoyland <jonathan.hoyland@gmail.com> wrote:
>> Hi All,
>>
>> This is something I'm very interested in.
>>
>> Definitely want to participate.
>>
>> Regards,
>>
>> Jonathan
>>
>> On Tue, 21 Jan 2020 at 10:04, Mohit Sethi M <mohit.m.sethi=40ericsson.com@dmarc.ietf.org> wrote:
>> I would let CFRG deal with the PAKE selection process:
>> https://mailarchive.ietf.org/arch/msg/cfrg/-a1sW3jK_5avmb98zmFbCNLmpAs
>> and not have this design team spend time and energy on designing PAKEs.
>>
>> --Mohit
>>
>> On 1/21/20 11:52 AM, Björn Haase wrote:
>>> Hello to all,
>>>
>>> I am also willing to contribute. My concern is that I observe that in some industrial control applications, PSK mechanisms (that actually require high-entropy keys) are (mis)-used in conjunction with TLS, where the PSK is actually of insufficient entropy (maybe derived only from a 4 digit PIN).
>>>
>>> In order to fix this issue, I'd really appreciate to have an PSK-style TLS operation using a balanced PAKE (note that this could be implemented with virtually no computational overhead in comparison to conventional ECDH session key generation).
>>>
>>> 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.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.
>>>
>>>
>>>
>>>
>> 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 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.
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>>> Von: TLS <tls-bounces@ietf.org> Im Auftrag von Mohit Sethi M
>>> Gesendet: Dienstag, 21. Januar 2020 10:45
>>> An: Colm MacCárthaigh <colm@allcosts.net>et>; Sean Turner <sean@sn3rd.com>
>>> Cc: TLS List <tls@ietf.org>
>>> Betreff: Re: [TLS] External PSK design team
>>>
>>> I am certainly interested and willing to contribute. We need some
>>> consensus on whether PSKs can be shared with more than 2 parties,
>>> whether the parties can switch roles, etc.
>>>
>>> EMU is going to work on EAP-TLS-PSK and the question of
>>> privacy/identities will pop-up there too.
>>>
>>> --Mohit
>>>
>>> On 1/21/20 7:33 AM, Colm MacCárthaigh wrote:
>>>> Interested, as it happens - this is something I've been working on at Amazon.
>>>>
>>>> On Mon, Jan 20, 2020 at 8:01 PM Sean Turner <sean@sn3rd.com> wrote:
>>>>> At IETF 106, we discussed forming a design team to focus on external PSK management and usage for TLS. The goal of this team would be to produce a document that discusses considerations for using external PSKs, privacy concerns (and possible mitigations) for stable identities, and more developed mitigations for deployment problems such as Selfie. If you have an interest in participating on this design team, please reply to this message and state so by 2359 UTC 31 January 2020.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Joe and Sean
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> TLS@ietf.org
>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C5af7f9dcd2f746b6638a08d79e56a7dc%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637151967330246544&amp;sdata=xtt%2F1mxS0XbrTQ8mExdzUP%2F%2BHSJKrXANsVqsX%2F4sUZA%3D&amp;reserved=0
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C5af7f9dcd2f746b6638a08d79e56a7dc%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637151967330246544&amp;sdata=xtt%2F1mxS0XbrTQ8mExdzUP%2F%2BHSJKrXANsVqsX%2F4sUZA%3D&amp;reserved=0
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls