Adding such a mode would add additional complexity that might lead to 
vulnerabiltiies, e.g. implementations that can be tricked into using a 
nonencrypted mode.
[[stf]] in principle yes, as this simplifies the configuration and policy 
handling. On the other hand it is a security policy point to allow certain 
cipher suites. 

It's been a trend in the tls working group to
a) reduce complexity when possible.
[[stf]] understood, makes operation less error prone

b) not try to accomodate obscure use cases that aren't relevant for the 
majority of TLS use cases.
[[stf]] well, as TLS is used in use cases like energy automation, industrial 
control, railway automation etc. there is an increasing number of use cases 
applying TLS and there are some, which would leverage integrity only for 
allowing for monitoring

Thus I assume a null cipher won't find support here. If you want to have 
traffic inspection with TLS imho the right way is to support that at the end 
points (let alone any arguments why you're doing traffic inspection in the 
first place and whether those reasons are good ones).
[[stf]] In principle yes, but the endpoints are often limited and may not 
support this type of functionality. Again, the traffic inspection in automation 
related communication is done for auditing and monitoring of the control flow. 
In the example of energy automation, TLS is always used with mutual 
authentication. So both peers know each other.

If you don't like that then TLS may be not the right protocol for your use case.
[[stf]] It was possible to now and it is good to rely on a protocol like TLS, 
which is defined and discussed in this way in the IETF. In the IEC (which is 
engaged I energy automation communication definition) there is the desire to 
use standardized security protocols available to avoid the definition of own 
solutions, whenever possible.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to