Without taking a position on null cipher suites, I would observe that the new TLS IANA rules will let you register your own (non-standard, non-recommended) code points for integrity-only suites.
-Ekr On Wed, Apr 5, 2017 at 10:14 AM, Fries, Steffen <steffen.fr...@siemens.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
