[TLS] Use-case for non-AEAD ciphers in network monitoring

Florian Wilkens <wilkens@informatik.uni-hamburg.de> Mon, 17 May 2021 16:24 UTC

Return-Path: <wilkens@informatik.uni-hamburg.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C2BF83A3E99 for <tls@ietfa.amsl.com>; Mon, 17 May 2021 09:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9hl8Hc_ykDfp for <tls@ietfa.amsl.com>; Mon, 17 May 2021 09:24:02 -0700 (PDT)
Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de []) (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 BBCB93A3E84 for <tls@ietf.org>; Mon, 17 May 2021 09:24:01 -0700 (PDT)
Received: from localhost (localhost []) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 227EBA3E; Mon, 17 May 2021 18:23:59 +0200 (CEST)
X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de
Received: from mailhost.informatik.uni-hamburg.de ([]) by localhost (mailhost.informatik.uni-hamburg.de []) (amavisd-new, port 10024) with LMTP id YW3NieQElES7; Mon, 17 May 2021 18:23:55 +0200 (CEST)
Received: from [] (ip1f11a148.dynamic.kabel-deutschland.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: wilkens) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id DDF79A3D; Mon, 17 May 2021 18:23:54 +0200 (CEST)
To: tls@ietf.org
From: Florian Wilkens <wilkens@informatik.uni-hamburg.de>
Message-ID: <b084b7a8-80a9-c7d9-fca7-dabb12ad6949@informatik.uni-hamburg.de>
Date: Mon, 17 May 2021 18:23:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bZYBNFmYS9unirD4L3E86qvlvPBl1pfiv"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Y1Zs5MhFiMhP8T8bgTICnJN-ycY>
Subject: [TLS] Use-case for non-AEAD ciphers in network monitoring
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 17 May 2021 16:25:19 -0000

Hey folks,

we came across a novel use-case that highlights the need for non-AEAD
ciphers in TLS and would like to start a discussion on that.

Our use-case is passive TLS decryption on network monitors (NMs).
Non-AEAD ciphers would allow  to selectively forward the TLS write keys
from clients to a NM that can then passively decrypt TLS sessions,
without touching their integrity (as the write MAC keys remain on the
host). This would be a major improvement compared to the usage of MitM
proxies as current state of the art. MitM proxies terminate all TLS
connections and establish own connections. Thus, a compromised MitM
proxy cannot only decrypt all packets, but also change packet contents.

We propose an approach for passive TLS decryption [1] in which
cooperating hosts selectively forward TLS keys to the NM that then
decrypts TLS sessions. The approach is (i) completely passive and thus
does not interfere with the overall connection security and (ii) is able
to selectively decrypt certain TLS connections with the hosts retaining
full authority over the key material. While a MitM proxy can also claim
to selectively decrypt traffic, we can guarantee this by keeping key
material for selected connections on the client. Furthermore, for
non-AEAD ciphers only the write keys, but not the write MAC keys, are
forwarded, so that the NM can inspect but not modify TLS packets.

Our prototype is built for the Zeek network monitor [2] and is currently
in the process of being upstreamed with explicit interest from the
maintainers [3]. Once merged, this will be the first open-source
solution for passive TLS decryption on both client host (for which we
built a small prototype) and network monitor (Zeek).

We understand that AEAD ciphers offer many advantages and we understand
the decision to limit the set of available ciphers to secure choices
only. However, we think the use-case of passive TLS decryption is highly
relevant especially for enterprise settings. In such settings, mainly
MitM proxies are used that are a security problem on their own.

We look forward to your feedback.


[1] https://arxiv.org/abs/2104.09828
[2] https://zeek.org
[3] https://github.com/zeek/zeek/pull/1518

M.Sc. Florian Wilkens
Research Associate
Phone: +49 40 42883 2353

IT-Sicherheit und Sicherheitsmanagement (ISS)
Universität Hamburg
Fachbereich Informatik
Vogt-Kölln-Straße 30
22527 Hamburg