You are right, I did not take that option into account. But as you mentioned, it is non-standard and with the desire is to be interoperable as most as possible, proprietary enhancements are likely not to be favored.
best regards Steffen From: Eric Rescorla [mailto:e...@rtfm.com] Sent: Mittwoch, 5. April 2017 19:31 To: Fries, Steffen (CT RDA ITS) Cc: Hanno Böck; tls@ietf.org Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3 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<mailto: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<mailto:ha...@hboeck.de> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
