Hi John, > I don't think this draft should be published as long as it gives the idea > that sacrificing confidentiality has significant benefits for latency, > memory, processing power, and cost. This is in general not the case. There definitely are cases where this is true, and cases where it is not. I don't want to speculate as to percentage of each, but I am happy to add some language saying that there performance benefits are highly dependent on hardware and software architecture, and that these cipher suites will not offer a performance benefit in all cases.
> In many IoT radio systems with small frames this will leads to significantly > increased latency. I think that needs to be mentioned. I am fine mentioning that and I think it helps broaden the reach. >It would be more honest if the draft simply stated that "the are use cases >that require visibility". Many of these use cases were added at the request of various reviewers and contributors, so I do not want to remove them. I (and others) still believe that there are some cases where confidentiality provides little to no benefit. I think we have made efforts to note that this is not true in all cases (e.g. these ciphers suites being listed as not recommended, or adding specific language to the draft such as " The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but is presented here to enable interoperable implementation of a reduced security mechanism that provides authentication and message integrity without supporting confidentiality."). To your point though I am happy to call out visibility as a use here. Thanks, --Jack -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of John Mattsson Sent: Wednesday, February 10, 2021 4:15 AM To: TLS@ietf.org Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites Hi, - The draft has a lot of claims regarding benefits: "strong requirement for low latency." "minimize the cryptographic algorithms are prioritized" "important for latency to be very low." "pay more for a sensor with encryption capability" "come with a small runtime memory footprint and reduced processing power, the need to minimize" the number of cryptographic algorithms used is prioritized." I don't think this draft should be published as long as it gives the idea that sacrificing confidentiality has significant benefits for latency, memory, processing power, and cost. This is in general not the case. The two cipher suites TLS_SHA256_SHA256 and TLS_SHA384_SHA384 defined by the draft causes much more message expansion (32 and 48 bytes tags instead of 16 or 8 bytes) than the already registered cipher suites for TLS 1.3. In many IoT radio systems with small frames this will leads to significantly increased latency. I think that needs to be mentioned. - The draft has ridiculous amount of sentences saying that confidentiality is not strictly needed. "do not require confidentiality" "privacy is not strictly needed" "no strong requirement for confidentiality" "no requirement to encrypt messages" "no need for confidentiality" "reduced need for confidentiality" "confidentiality requirements are relaxed" "do not require confidential communications" "does not convey private information" "without requiring the communication to/from the robotic arm to be encrypted" "doesn't grant the attacker information that can be exploited" "no confidentiality requirements" It would be more honest if the draft simply stated that "the are use cases that require visibility". If visibility is not a requirement for the use cases, I think IETF could help you to standardize SHA-2 only cipher suites offering confidentiality. - The draft mentions that the security considerations regarding confidentiality and privacy does not hold. The draft does not mention that it breaks one of the stated security properties of TLS 1.3, namely "Protection of endpoint identities". This is actually quite problematic. EAP-TLS 1.3 relied on this stated TLS 1.3 property to be true. John _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!JhrIYaSK6lFZ!7EjueedGEojT6_EE6rVv6m7p6xV7TIVa0Jh6mtrMbM3qQbIW4M6C36Dzb4359xnpB5-_$ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
