Closed elear closed 1 month ago
Also add some text about use of RFC 9150 (not always, not never, but parameterized as when one might consider it).
Also add some text about use of RFC 9150 (not always, not never, but parameterized as when one might consider it).
Hi @elear, unfortunately, I wasn't in the IOTOPS meeting and I may not have the full context, but referencing an approach that "[...] is not endorsed by the IETF and does not have IETF consensus" is going to be tricky. Would you help us craft such text?
Eliot, it would be a good idea to provide some guidance about how you want to frame this. I agree that the use of a Diffe-Hellman exchange only provides perfect forward secrecy when encryption is used.
Hi, just some thoughts regarding the use of integrity only cipher suites in automation environments. I provided some use cases to RFC 9150, which relate to railway scenarios as well as power system automation. In both cases integrity only is desired to enable monitoring but to ensure authenticity of the exchanged information. RFC 9150 already provides recommendations for IoT at the end of the security considerations.
@hannestschofenig : I disagree with the statement regarding perfect forward secrecy. This property relates not only to the data but also to the established key. That said, when using integrity only, I would consider PFS for the key as equally important as in the confidentiality case.
@stfries: I guess we a new term would be appropriate since PFS has a certain meaning, namely one tied to secrecy of the content, and in this case we would be talking about "perfect forward integrity".
Interesting point. I always interpreted PFS in the context of the key management and related to the secrecy of the key more or less independent of the actual usage of the key for integrity or confidentiality or both. Well, the term in general may require some interpretation as it is intended for backward security ;-)
Not all suites offer pfs. See RFC 9150.