Hiya,
I realise it's not proposed as a wg document, but fwiw, I think John is quite correct below. The only additional point I'd add is that I've seen cases over the years where the fact that confidentiality really *is* required only became clear when people actually considered how to attack systems. I'd be happy to bet beers that will be the case with some examples mentioned in the draft, esp the wandering robotic arm. This seems like a not that well done write-up of a bad idea to me. S. On 10/02/2021 09:14, John Mattsson wrote:
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://www.ietf.org/mailman/listinfo/tls
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
