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 <filippo@ml.filippo.io> wrote:
> 
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann <pgut001@cs.auckland.ac.nz <mailto:pgut001@cs.auckland.ac.nz>>:
>> John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org <mailto:40ericsson.com@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>