Re: [TLS] Use-case for non-AEAD ciphers in network monitoring
Florian Wilkens <wilkens@informatik.uni-hamburg.de> Wed, 26 May 2021 08:49 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A649D3A26BB for <tls@ietfa.amsl.com>; Wed, 26 May 2021 01:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAeDWXIJOLlM for <tls@ietfa.amsl.com>; Wed, 26 May 2021 01:49:08 -0700 (PDT)
Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 603A53A24B9 for <tls@ietf.org>; Wed, 26 May 2021 01:49:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E9082A29 for <tls@ietf.org>; Wed, 26 May 2021 10:49:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de
Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DbWmVeP8gcdC for <tls@ietf.org>; Wed, 26 May 2021 10:49:04 +0200 (CEST)
Received: from [192.168.178.30] (ip1f11a148.dynamic.kabel-deutschland.de [31.17.161.72]) (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 29A5FA25 for <tls@ietf.org>; Wed, 26 May 2021 10:49:02 +0200 (CEST)
From: Florian Wilkens <wilkens@informatik.uni-hamburg.de>
To: tls@ietf.org
References: <b084b7a8-80a9-c7d9-fca7-dabb12ad6949@informatik.uni-hamburg.de>
Message-ID: <584db921-4c57-4f45-65d6-8273611fd549@informatik.uni-hamburg.de>
Date: Wed, 26 May 2021 10:48:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <b084b7a8-80a9-c7d9-fca7-dabb12ad6949@informatik.uni-hamburg.de>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="I3agZDKU5dUKJiq1Lz8uH9lqhdBrftcUm"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vJJjoCuLwFbrXudB9IxreM6e7Ss>
Subject: Re: [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: Wed, 26 May 2021 08:49:14 -0000
Dear all, first, we want to thank you for your feedback, it is much appreciated! We wanted to briefly clarify some details about our idea: - AEAD/non-AEAD: completely true. We were mainly looking at ciphers from TLS 1.3 that all use keys and IVs but that is of course unrelated to AEAD as a concept. - registering our own ciphersuite: while that is certainly an option, we are not really advocating for new cipher suites but rather keeping at least a single cipher suite in the standard that allows for separate keys for confidentiality and integrity. We also tried to catch up on the discussions in 2016/2017 around industry concerns to TLS 1.3 (regarding PFS and static key exchanges). While some parts are certainly similar, we think our approach is different, as we do not aim to weaken the overall connection security but rather keep the client machine in control of the key material (as it is already with current TLS). To be clear, our prototype already works on current TLS as is. The client sends either the pre-master-secret or derived session keys to the network monitor. Naturally, this will continue to work with future TLS versions as the client ultimately possesses all required key material. There are certainly scenarios in which an enterprise might still want to deploy an MitM proxy at the network edge to retain more control, however our approach is able to avoid the disadvantages induced by these proxies. In fact multiple commercial offerings (including one proposed on the linked NIST workshop) already do exactly what we propose and hand over all key material to a central party for decryption. Whether this is good practice, is a discussion for another time, but it is already happening anyway and there is demand for these solutions. Our prototype is able to slightly decrease the attack surface on the network monitor, as it is not able to forge valid packets in the same connection due to the missing integrity key. The impact on application protocols such as HTTP is a problem, however this problem is also present on both commercial solutions that exfiltrate all key material from the client and MitM proxies. Overall, we just wanted to raise some awareness for the use case as we felt that a small change to a future TLS standard could achieve some slight improvements regarding the network monitor. However, if that does not match the WG's opinion that is certainly okay, as we can work with current TLS. So again thank you for you feedback! Cheers, Florian On 17.05.21 18:23, Florian Wilkens wrote: > 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. > > Best, > Florian > > [1] https://arxiv.org/abs/2104.09828 > [2] https://zeek.org > [3] https://github.com/zeek/zeek/pull/1518 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- 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 Deutschland
- [TLS] Use-case for non-AEAD ciphers in network mo… Florian Wilkens
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Salz, Rich
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Eric Rescorla
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Darin Pettis
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Darin Pettis
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Stephen Farrell
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Eric Rescorla
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Darin Pettis
- Re: [TLS] [EXTERNAL] Re: Use-case for non-AEAD ci… Andrei Popov
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Ruslan N. Marchenko
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Florian Wilkens
- Re: [TLS] Use-case for non-AEAD ciphers in networ… Martin Thomson