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

Hanno Böck <hanno@hboeck.de> Tue, 04 April 2017 16:08 UTC

Return-Path: <hanno@hboeck.de>
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 12F391294C3 for <tls@ietfa.amsl.com>; Tue, 4 Apr 2017 09:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 TLi1Iicf11Y5 for <tls@ietfa.amsl.com>; Tue, 4 Apr 2017 09:08:41 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DFF127775 for <tls@ietf.org>; Tue, 4 Apr 2017 09:08:41 -0700 (PDT)
Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 04 Apr 2017 18:08:40 +0200 id 0000000000000060.0000000058E3C508.00002C64
Date: Tue, 04 Apr 2017 18:08:38 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20170404180838.08ca99cc@pc1>
In-Reply-To: <E6C9F0E527F94F4692731382340B337847DB9A@DENBGAT9EH2MSX.ww902.siemens.net>
References: <E6C9F0E527F94F4692731382340B337847DB9A@DENBGAT9EH2MSX.ww902.siemens.net>
X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xSv32fBV3AcCsJqlvXWlbr9fw5k>
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: Tue, 04 Apr 2017 16:08:45 -0000

On Mon, 3 Apr 2017 16:17:45 +0000
"Fries, Steffen" <steffen.fries@siemens.com> wrote:

> The reason I'm asking is that in industrial communication it is often
> sufficient to have source authentication and message integrity while
> probes on the network are still able to monitor the traffic for
> certain properties or verify allowed exchanges. An example is ICCP
> for inter control center communication. The two control center are
> connected via an IPSec tunnel terminated in the DMZ. The desire is to
> have the TLS tunnel end-to-end to allow for source authentication and
> also for message integrity, while doing traffic inspection in the
> DMZ. There exist other scenarios, with a similar requirement.

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.

It's been a trend in the tls working group to
a) reduce complexity when possible.
b) not try to accomodate obscure use cases that aren't relevant for the
majority of TLS use cases.

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).
If you don't like that then TLS may be not the right protocol for your
use case.

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

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