Re: [TLS] Support of integrity only cipher suites in TLS 1.3

"Fries, Steffen" <steffen.fries@siemens.com> Wed, 05 April 2017 17:14 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687671200C1 for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 10:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbQlx-HboZfc for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 10:14:16 -0700 (PDT)
Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF60D127775 for <tls@ietf.org>; Wed, 5 Apr 2017 10:14:15 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id v35HE8Vb021142 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Apr 2017 19:14:08 +0200
Received: from DEFTHW99ERIMSX.ww902.siemens.net (defthw99erimsx.ww902.siemens.net [139.22.70.134]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v35HE32c019820 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Apr 2017 19:14:03 +0200
Received: from DEFTHW99ER1MSX.ww902.siemens.net (139.22.70.71) by DEFTHW99ERIMSX.ww902.siemens.net (139.22.70.134) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 5 Apr 2017 19:14:03 +0200
Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.223]) by DEFTHW99ER1MSX.ww902.siemens.net ([139.22.70.71]) with mapi id 14.03.0339.000; Wed, 5 Apr 2017 19:14:02 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Hanno Böck <hanno@hboeck.de>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Support of integrity only cipher suites in TLS 1.3
Thread-Index: AdKsldO7ZRItAwyZRXCzcLu6YsWN5QAtyDcAADhSsSA=
Date: Wed, 05 Apr 2017 17:14:01 +0000
Message-ID: <E6C9F0E527F94F4692731382340B337847F4BE@DENBGAT9EH2MSX.ww902.siemens.net>
References: <E6C9F0E527F94F4692731382340B337847DB9A@DENBGAT9EH2MSX.ww902.siemens.net> <20170404180838.08ca99cc@pc1>
In-Reply-To: <20170404180838.08ca99cc@pc1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.22.70.49]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4JVHcwRwd6Don4KPhlRuggDKIEc>
Subject: Re: [TLS] Support of integrity only cipher suites in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Apr 2017 17:14:18 -0000

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: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

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