[TLS]Re: Curve-popularity data?
Hello to all, I fear that regarding the "Curve-popularity" data there might be too much of "opinion" and "company policies" and "government policies" around which IMHO can be an obstacle for constructive discussion. And it seems again to be a discussion between Short-Weierstrass curves on the one side and the modern Montgomery/Edwards curves on the other side. I think that for getting forward, we probably best try to get a step back and try to formulate consensus on the actual requirements behind the reasonings and establish a clearer picture regarding the system architectures that people have in mind. In my perspective, the "security" space at least has at least 4 dimensions relevant here: - Firstly, the biggest security risk might be that no or worse crypto is used in an application (e.g. no ephemeral session keys instead of session-specific DH) because DH is considered to be too costly. - The second dimension might be that crypto is poorly implemented and implementation attacks become feasible. - The third dimension is the risk of hardware-side-channels and the risk of leaked private long-term keys. IMO this issue can only be resolved when using special hardware components for guarding and protecting the private keys and mandatory requires secure elements. - The fourth dimension is the fear regarding future QC attacks. In addition to these dimensions I believe that we need to consider where applications need to store their keys. For ephemeral session-key-related secrets I don't see the immediate use-case of storing the private keys in a secured hardware (TPM or Secure element). However this (IMHO) should really be different for all of the private long-term keys used for authenticating a session (e.g. server certificates). IMO its not only the fact that hardware elements can better protect the keys but good use of hardware-chips for authentication secrets also avoid slopply management of keys! Regarding curve popularity (unfortunately) most chipsets that offer hardware protection are using short-Weierstrass curves, however there are also newer chipsets which also support Ed25519 or Ed448 but that's currently not the majority. However this reasoning should (IMO) apply only to the authentication part of TLS and not regarding the session-key establishment (and DH). Actually in my opinion it is only the third dimension mentioned above in combination with today's restriction regarding secure-element chipsets from which an advantage for P-256 or P-384 shows up. In my system picture, we might best optimize future TLS for a distributed architecture with one or two CPUs for the crypto. One CPU A which manages the session-key establishment and bulk crypto (the main CPU of the system) and a second CPU B which handles the protocol parts for authentication which might come with hardware-level-security and a protected persistent storage for keys (possibly split off to a TPM or Secure element). As a result, I would suggest that regarding key-establishment one might be better off with promoting the newer and more efficient X25519 and X448 in combination with PQ-Algorithms for the CPU A part as this might optimize for the dimensions 1,2 and 4. Regarding the algorithms for the CPU B part, we probably should try to split off the algorithm requirements and run a separate assessment. The better current support for hardware-security for key storage which is a big plus for P-256 today for the CPU B parts. A big part of the discussion here might be that different people have different system architectures in mind. Yours, Björn. Mit freundlichen Grüßen | Best Regards Dr. Björn Haase Senior Expert Electronics | TGREH Electronics Hardware Endress+Hauser Liquid Analysis Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany Phone: +49 7156 209 10377 bjoern.ha...@endress.com | www.ehla.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 con
[TLS]Re: Curve-popularity data?
Hi Eric, Hi all, >One more thing: we are finalizing RFC 8446-bis right now, so if there is >WG consensus to require that clients offer all MTI curves in the key_shares >of their initial CH, then that would be a straightforward text change. I think that we might rather keep a mechanism that preserves the possibility of the client-side to express a preference regarding a specific cipher suite / curve and accept other curves only using the HRR-mechanism. E.g. a client might also have legitimate reasons to nudge servers to use a stronger curve than P-256 in the initial CH and only fall back to weaker curves by explicit request via HRR. Probably the reason for Chrome for requesting HRR for P-256 is the attempt to nudge servers to use an algorithm which is believed to provide advantages for the client-side implementation (possibly both, speed/power or security or bandwidth) in comparison to P-256. Björn. Mit freundlichen Grüßen | Best Regards Dr. Björn Haase Senior Expert Electronics | TGREH Electronics Hardware Endress+Hauser Liquid Analysis Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany Phone: +49 7156 209 10377 bjoern.ha...@endress.com | www.ehla.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. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
Re: [TLS] tls-external-psk-guidance // Draft for a suggestion of string encoding for manually typing a PSK is available
Hello to all, in the process of the discussions of the external PSK guidance document, it was considered to suggest an encoding for PSK for applications that need to enter the key by manual typing. Presently such applications might be tempted to allow for strings such as "banana" as PSK which is considered to be a bad idea. I have prepared a very rough suggestion, on how an encoding could be defined that would require assistance from a tool and might enforce some minimum level of entropy. Moreover such an encoding might be more user friendly, since a certain level of typing errors could be distinguished from authentication failures. A first suggestion as basis for a discussion is now online at https://datatracker.ietf.org/doc/draft-haase-psk-encoding/ Yours, Björn. Am 09.03.2020 um 20:17 schrieb Christopher Wood: This document is the first checkpoint for the External PSK design team started a few weeks back. Feedback in the form of comments, edits, or PRs [1] is welcome! Thanks, Chris (no hat) [1] https://github.com/tlswg/external-psk-design-team - Original message - From: internet-dra...@ietf.org To: "Christopher A. Wood" , Mohit Sethi , Jonathan Hoyland , Christopher Wood , Russ Housley Subject: New Version Notification for draft-dt-tls-external-psk-guidance-00.txt Date: Monday, March 09, 2020 12:10 PM A new version of I-D, draft-dt-tls-external-psk-guidance-00.txt has been successfully submitted by Christopher A. Wood and posted to the IETF repository. Name: draft-dt-tls-external-psk-guidance Revision: 00 Title: Guidance for External PSK Usage in TLS Document date: 2020-03-09 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-dt-tls-external-psk-guidance-00.txt Status: https://datatracker.ietf.org/doc/draft-dt-tls-external-psk-guidance/ Htmlized: https://tools.ietf.org/html/draft-dt-tls-external-psk-guidance-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-dt-tls-external-psk-guidance Abstract: This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS. It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. It provides advice for applications in various use cases to help meet these assumptions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ 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
Re: [TLS] External PSK design team // Scope for "Low-entropy PSK" applications
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 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 Gesendet: Dienstag, 21. Januar 2020 15:52 An: Jonathan Hoyland Cc: Mohit Sethi M ; Björn Haase ; TLS List Betreff: Re: [TLS] External PSK design team I am willing to contribute. -Ekr On Tue, Jan 21, 2020 at 2:50 AM Jonathan Hoyland 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 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 privileg
Re: [TLS] External PSK design team // Scope for "Low-entropy PSK" applications
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 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. Von: Eric Rescorla Gesendet: Dienstag, 21. Januar 2020 15:52 An: Jonathan Hoyland Cc: Mohit Sethi M ; Björn Haase ; TLS List Betreff: Re: [TLS] External PSK design team I am willing to contribute. -Ekr On Tue, Jan 21, 2020 at 2:50 AM Jonathan Hoyland mailto: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 mailto:40ericsson@dmarc.ietf.org>> wrote: I would let CFRG deal with the PAKE selection process: https://mailarchive.ietf.org/arch/msg/cfrg/-a1sW3jK_5avmb98zmFbCNLmpAs<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcfrg%2F-a1sW3jK_5avmb98zmFbCNLmpAs&data=02%7C01%7Cbjoern.haase%40endress.com%7C85118d6ee98248a1f7f308d79e819bea%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637152151820406718&sdata=A830vq0AbXV5EnAGgvMFk%2F5nZEn1HLY8lwYxkK311ns%3D&reserved=0> 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<mailto:bjoern.ha...@endress.com> | > www.conducta.endress.com<http://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 confi
Re: [TLS] External PSK design team
> Mohit Sethi M wrote: > I would let CFRG deal with the PAKE selection process: > and not have this design team spend time and energy on designing PAKEs. That was not what I was suggesting. Instead, I was suggesting to *incorporate* the results of the selection process into TLS, such that there is an option allowing for security also in case of a "Low-Entropy"-PSK. Possibly, if the PAKE substep actually happens to be no more complex than Diffie-Hellmann, it might be worth to consider the PAKE as the default mechanism for any PSK-based key establishment that authenticates an ephemeral new session key with a PSK mechanism.? 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] External PSK design team
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. -Ursprüngliche Nachricht- Von: TLS Im Auftrag von Mohit Sethi M Gesendet: Dienstag, 21. Januar 2020 10:45 An: Colm MacCárthaigh ; Sean Turner Cc: TLS List 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 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
Re: [TLS] draft-barnes-tls-pake
Dear Rob, you might know that currently there is an ongoing PAKE selection process in the context of the CFRG working group. SRP is no longer considered there. In my opinion, SRP comes with several problems. It’s patent circumvention approach did consider patents that today are expired. This patent circumvention made 1.) the protocol computationally very complex and 2.) prevented through security analysis/proofs. (See e.g. the discussion in https://eprint.iacr.org/2018/286 in section 2.1.). Regarding the complexity: I did analyze SRP once for the computational constraints of the setting https://eprint.iacr.org/2017/562. There SRP would have resulted in about two minutes (120 s!) login delay for 1024 bit field size (80 bit symmetric security level) because of the complexity of the computations on the constrained embedded server. With today’s alternatives (see, e.g. https://eprint.iacr.org/2018/286) using Montgomery or Edwards curves, you could realize 2-4 seconds for the 128 bit security level for the very same constraint setting. So for security-proof reasons and for efficiency for embedded devices there is a need for alternative PAKE protocols. There draft-barnes-tls-pake describes one out of several possible approaches. 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. Von: TLS Im Auftrag von Rob Sayre Gesendet: Mittwoch, 4. September 2019 01:05 An: tls@ietf.org Betreff: [TLS] draft-barnes-tls-pake Hello, I read https://tools.ietf.org/html/draft-barnes-tls-pake-04<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-barnes-tls-pake-04&data=02%7C01%7Cbjoern.haase%40endress.com%7C0dd3e93d68f84993d53d08d730c33ea0%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637031487436897945&sdata=4UZhHwWpFl%2Bg1R3Ocoz7JbJ2NKndciKI3eDLvcpboQg%3D&reserved=0>. I understand and agree that the SRP scheme in RFC 5054 might not apply cleanly to TLS 1.3. However, I don't understand the rationale for choosing other PAKE algorithms for this draft over SRP. I found that Apple iCloud and HomeKit use SRP, so it seemed strange to choose other algorithms in this draft, given the popularity of those products. I'm not pushing an agenda here. I just want to understand. But, I found the rationale in the various draft-barnes-tls-pake drafts very unenlightening. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
