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

Martin Thomson <mt@lowentropy.net> Wed, 26 May 2021 22:00 UTC

Return-Path: <mt@lowentropy.net>
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 4E9ED3A0D01 for <tls@ietfa.amsl.com>; Wed, 26 May 2021 15:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=2uhlmcDQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VsTLOHqw
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 26ScGMJYN8dw for <tls@ietfa.amsl.com>; Wed, 26 May 2021 15:00:52 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999EC3A0CFC for <tls@ietf.org>; Wed, 26 May 2021 15:00:52 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B31905C0164 for <tls@ietf.org>; Wed, 26 May 2021 18:00:49 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Wed, 26 May 2021 18:00:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=9B+Tj NuMmBXylUVN7JVBZnMSy1AxFl2HQhjY3cAfcuY=; b=2uhlmcDQNLr9z2fXsW7un qosUH3+MrhH/cL+4e2oojatgxXAyTcQ3xoj8A59qsfBJIPfWTMYkXSQkJTq1yaY5 /LPK9qZtCEaHqzaW87U1ntIJ0LBSKbQF/bC1JFzXezwFHhS2Ahr5uZXYm4KFt+Wq vsXa6tbz9u5r09KlLOsVzuPXqyl0hvuXJpTuulxtj+mSTOBeEcHYVx+kw8w2wV5d 8/9kTKPJUwxWUWxkMkyAbylL/21cVmRiri2VohwVHBOpar6/9K+iUbcXWjYts5ro hynlBcBy6yji4qD8NcSICcCLmHXnLfqSBN9QtKnGVxehYY4w68WoQrbCFAwhr8XU Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=9B+TjNuMmBXylUVN7JVBZnMSy1AxFl2HQhjY3cAfc uY=; b=VsTLOHqwdV+JLrq2A+/n6fqMeo5ZzOVZGIKeoqTyupQB9rwiQ8/C9XdjN For5kVErV+MCYLwhF8cH5+uW22RoU0rxsw95FIvN5eulEYVspitb5EjkH1n6vZOC //8t3YtYw7Hj94ikbqMPqZ/QsY12OFo+Zo8zGTUWko9o1qg8uWsTlZUQd+krB+9d swCAuIQZbO8v05pTDf+Glq3/3BcskIrrPhLp1UKq+RvaxCjcbCMZThKs0I5Gu3TB qyNKdcbD2tFyBas8XyfVcI51kA3+eDCDDGKQbNy/BrtpOTTV6Y93E8BFc8GnXryX qnTafB5bu77JvEwkSQZHuvOV/JZ0g==
X-ME-Sender: <xms:EMWuYFz5E2MeEVvkLgz3PZJDTbIOBWmYgqI28FpTJuaIYWaiuaG28A> <xme:EMWuYFTwTxKJdy99VkmhbyhsVQkoVhDfQ4Z5bBelPlolOfoftMYPBj1zxPQhkO3XA s59S1ieerCfmLI5_y4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekgedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptddvteduieefveffte etgfegueffjeehjeeiledthffhgeehveeijefgkedtleejnecuffhomhgrihhnpegrrhig ihhvrdhorhhgpdiivggvkhdrohhrghdpghhithhhuhgsrdgtohhmpdegtdhivghtfhdroh hrghdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:EMWuYPUjxfq_dyHI7r2dW9ZtBOcVVxIt1Q8YTLGehKvZbbSuIbz6ig> <xmx:EMWuYHjZ_cTEr4A3nV-s7SasO3njd99IJzi6HudyPo-YY7XHxtbEUA> <xmx:EMWuYHAsW7jKInxiI_0OJAG_ck4gm4-lKQWWgYh6ePW9DOVpWbHQhw> <xmx:EcWuYKOzD-ifqjD3GaM3UrPOCj_aIRinfea92GmAdgRKcedBmaREaw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B46094E0091; Wed, 26 May 2021 18:00:48 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-Id: <8eedb189-7fb1-4a18-b68d-ee74ea130799@www.fastmail.com>
In-Reply-To: <584db921-4c57-4f45-65d6-8273611fd549@informatik.uni-hamburg.de>
References: <b084b7a8-80a9-c7d9-fca7-dabb12ad6949@informatik.uni-hamburg.de> <584db921-4c57-4f45-65d6-8273611fd549@informatik.uni-hamburg.de>
Date: Thu, 27 May 2021 08:00:28 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/27sveY-4chTH91Kf-H6vgnTCxWI>
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 22:00:58 -0000

It seems to me like the next step is to share a paper, ideally in the form of an internet-draft, that describes more precisely what you would like to see happen.

On Wed, May 26, 2021, at 18:48, Florian Wilkens wrote:
> 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 <mailto:TLS%40ietf.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 mailing list
> TLS@ietf.org <mailto:TLS%40ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
> 
> Attachments:
> * OpenPGP_signature