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 > <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>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls