> 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 > <mailto:fili...@ml.filippo.io>> wrote: > > 2020-09-19 13:48 GMT+02:00 Peter Gutmann <pgut...@cs.auckland.ac.nz > <mailto:pgut...@cs.auckland.ac.nz>>: > John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org > <mailto: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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
