I sincerely hope that the TLS group will NOT make the same decision [as LAKE - to drop PSK].
Regards, Uri > On Sep 23, 2020, at 07:50, Hannes Tschofenig <hannes.tschofe...@arm.com> > wrote: > > > 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. > > 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? > > Ciao > Hannes > > From: Carrick Bartle <cbartle...@icloud.com> > Sent: Monday, September 21, 2020 6:19 PM > To: Hannes Tschofenig <hannes.tschofe...@arm.com> > Cc: Carrick Bartle <cbartle891=40icloud....@dmarc.ietf.org>; Filippo Valsorda > <fili...@ml.filippo.io>; tls@ietf.org > 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 <hannes.tschofe...@arm.com> > 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 <tls-boun...@ietf.org> On Behalf Of Carrick Bartle > Sent: Monday, September 21, 2020 5:31 AM > To: Filippo Valsorda <fili...@ml.filippo.io> > Cc: tls@ietf.org > 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 <fili...@ml.filippo.io> wrote: > > 2020-09-19 13:48 GMT+02:00 Peter Gutmann <pgut...@cs.auckland.ac.nz>: > John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> 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 > TLS@ietf.org > 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 > TLS@ietf.org > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
