Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig <[e-mail]>]

Hi Filippo,

I worry that labelling ciphersuites that is deployed in parts of the industry as “not recommended” will confuse those who look at the IANA website.

Only those readers who look at the note will then learn that not recommended means three things, whereby the option "has not been through the IETF consensus process" should not give readers great confidence either.

I hope this explains my concern.

There is no problem with the use of these PSK ciphersuites, so why mark them as “not recommended”?

Ciao
Hannes

From: Filippo Valsorda <[e-mail]>
Sent: Wednesday, September 23, 2020 3:39 PM
To: Hannes Tschofenig <[e-mail]>; Carrick Bartle <[e-mail]>
Cc: [e-mail]
Subject: Re: [TLS] The future of external PSK in TLS 1.3

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>:

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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Cc: Carrick Bartle <cbartle891=[e-mail]<mailto:cbartle891=[e-mail]>>; Filippo Valsorda <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:



2020-09-19 13:48 GMT+02:00 Peter Gutmann <[e-mail]<mailto:[e-mail]>>:

John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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.

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.