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

[Björn Haase <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
>> Gesendet: Dienstag, 21. Januar 2020 15:52
>> An: Jonathan Hoyland <[e-mail]>
>> Cc: Mohit Sethi M <mohit.m.sethi=[e-mail]>; Björn Haase <[e-mail]>; TLS List <[e-mail]>
>> Betreff: Re: [TLS] External PSK design team
>>
>> I am willing to contribute.
>>
>> -Ekr
>>
>>
>> On Tue, Jan 21, 2020 at 2:50 AM Jonathan Hoyland <[e-mail]> 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=[e-mail]> 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: [phone] | Fax: [phone]
>>> [e-mail] |  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: [phone] | Fax: [phone]
>> [e-mail] |  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 <[e-mail]> Im Auftrag von Mohit Sethi M
>>> Gesendet: Dienstag, 21. Januar 2020 10:45
>>> An: Colm MacCárthaigh <[e-mail]>; Sean Turner <[e-mail]>
>>> Cc: TLS List <[e-mail]>
>>> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> 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
>>> [e-mail]
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls