2020-09-23 13:49 GMT+02:00 Hannes Tschofenig <[email protected]>: > Hi Carrick,
> > you note that SCADA is a pretty specific use case. SCADA sounds specific but > TLS is used widely in the IoT market. It is even used in devices that use > smart cards, which use TLS with PSK to protect their provisioning protocol. > > I am worried that marking a ciphersuite as N with the meaning that it "has > not been through the IETF consensus process, has limited applicability, or is > intended only for specific use cases" is hard for readers to understand which > of these three cases were actually the reason for marking it as “N”. The "has > not been through the IETF consensus process" will scare off many people. > > For most people the web is the generic case and everything else is a > “specific use case”. Sure, the web is very important but TLS is a generic > protocol used in many environments. By this reasoning, what is a specific use case? My interpretation is "anything you shouldn't use unless you have specific requirements". Compatibility with smart cards is clearly a specific requirement, and you should definitely use an ECDH PSK if you can. What's your interpretation? 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, regardless of whether they talk to browsers or other services. > I don’t understand John’s motivation. The LAKE group makes a decision to > remove PSK support. That’s good for them. Does this imply that the TLS group > also needs to make the same decision? (Again, no one is suggesting dropping anything, as far as I can tell.) > Ciao > Hannes > > *From:* Carrick Bartle <[email protected]> > *Sent:* Monday, September 21, 2020 6:19 PM > *To:* Hannes Tschofenig <[email protected]> > *Cc:* Carrick Bartle <[email protected]>; Filippo > Valsorda <[email protected]>; [email protected] > *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 > >> Can you justify your reasoning? > > Which part? > > >> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig <[email protected]> >> wrote: >> >> Hi Carrick, >> >> Can you justify your reasoning? >> >> The challenge I have with the work on IoT in the IETF that the preferences >> for pretty much everything changes on a regular basis. >> >> I don’t see a problem that requires a change. In fact, I have just posted a >> mail to the UTA list that gives an overview of the implementation status of >> embedded TLS stacks and PSK-based ciphersuites are widely implemented. >> >> Ciao >> Hannes >> >> *From:* TLS <[email protected]> *On Behalf Of *Carrick Bartle >> *Sent:* Monday, September 21, 2020 5:31 AM >> *To:* Filippo Valsorda <[email protected]> >> *Cc:* [email protected] >> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3 >> >> I'm also fine with marking psk_ke as not recommended to be consistent with >> the non-PFS ciphers, but there are plenty of valid use cases that justify >> keeping dhe_psk_ke as recommended for external PSKs. Several of these use >> cases are detailed in draft-ietf-tls-external-psk-guidance-00. >> >> >> >>> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda <[email protected]> wrote: >>> >>> 2020-09-19 13:48 GMT+02:00 Peter Gutmann <[email protected]>: >>>> John Mattsson <[email protected]> writes: >>>> >>>> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke >>>> >and >>>> >especially psk_ke are both marked as RECOMMENDED. If used in the initial >>>> >handshake, both modes have severe privacy problems, >>>> >>>> PSK is used a fair bit in SCADA. There are no privacy problems there. So >>>> just because there's a concern for one specific environment doesn't mean it >>>> should be banned for any use. In particular, I think if a specific >>>> industry >>>> has a particular concern, they should profile it for use in that industry >>>> but >>>> not require that everyone else change their behaviour. >>> >>> Indeed, if the SCADA industry has a particular need, they should profile >>> TLS for use in that industry, and not require we change the recommendation >>> for the open Internet. >>> >>> Setting Recommended to N is not "banning" anything, it's saying it "has not >>> been through the IETF consensus process, has limited applicability, or is >>> intended only for specific use cases". SCADA sounds like a pretty specific >>> use case. >>> >>> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke >>> wouldn't be marked N like all suites lacking PFS. >>> _______________________________________________ >>> TLS mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/tls >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
