Re: [TLS] The future of external PSK in TLS 1.3

2020-09-24 Thread Salz, Rich
>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS >or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards Even if this is true (proof by assertion): So what? Do those users not get to be a participant?

Re: [TLS] The future of external PSK in TLS 1.3

2020-09-24 Thread Pascal Urien
Hi all Payment terminal use TLS (see for example https://www.pcisecuritystandards.org/documents/Use-of-SSL-Early-TLS-for-POS-POI-Connections.docx ) They are not WEB browser...may be IoT devices ? because they are connected Le jeu. 24 sept. 2020 à 16:12, Filippo Valsorda a écrit : >

Re: [TLS] The future of external PSK in TLS 1.3

2020-09-24 Thread Filippo Valsorda
2020-09-24 12:02 GMT+02:00 Peter Gutmann : > Taking "SCADA/IoT/etc" to be a placeholder for M2M or more > generally "non-web use", [...] "The web" and "resource-constrained use cases which can't afford ECDH" feels like a false dichotomy, and it sounds unlikely that most M2M cases would fit the

Re: [TLS] The future of external PSK in TLS 1.3

2020-09-24 Thread Hannes Tschofenig
Nicely said, Peter. To add: this is also the reason why the UTA group has been working on two sets of documents to capture profiles for the web (+email+IM) and IoT: 1) RFC 7590 and now draft-ietf-uta-tls13-iot-profile-00 2) RFC 7525 and now draft-sheffer-uta-rfc7525bis -Original

Re: [TLS] The future of external PSK in TLS 1.3

2020-09-24 Thread Peter Gutmann
Filippo Valsorda writes: >The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS >or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards How do you know that? I don't know of any data supporting that (I'd love to see it if you've got it, non-web use of TLS is

Re: [TLS] The future of external PSK in TLS 1.3

2020-09-24 Thread Lanlan Pan
David Benjamin 于2020年9月24日周四 上午12:32写道: > It sounds like the registry may be confusing, so perhaps we, independent > of the existing criteria for Y vs N, need to do a better job of presenting > the information. That sounds like an orthogonal issue to whether psk_ke > should be marked as