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.ha...@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 <e...@rtfm.com>
Gesendet: Dienstag, 21. Januar 2020 15:52
An: Jonathan Hoyland <jonathan.hoyl...@gmail.com>
Cc: Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org>; Björn Haase
<bjoern.ha...@endress.com>; 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.hoyl...@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....@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.ha...@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.ha...@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-boun...@ietf.org> Im Auftrag von Mohit Sethi M
Gesendet: Dienstag, 21. Januar 2020 10:45
An: Colm MacCárthaigh <c...@allcosts.net>; Sean Turner <s...@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 <s...@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&data=02%7C01%7Cbjoern.haase%40endress.com%7C5af7f9dcd2f746b6638a08d79e56a7dc%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637151967330246544&sdata=xtt%2F1mxS0XbrTQ8mExdzUP%2F%2BHSJKrXANsVqsX%2F4sUZA%3D&reserved=0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cbjoern.haase%40endress.com%7C5af7f9dcd2f746b6638a08d79e56a7dc%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637151967330246544&sdata=xtt%2F1mxS0XbrTQ8mExdzUP%2F%2BHSJKrXANsVqsX%2F4sUZA%3D&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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
