From nobody Wed May 26 15:01:00 2021 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekgedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptddvteduieefveffte etgfegueffjeehjeeiledthffhgeehveeijefgkedtleejnecuffhomhgrihhnpegrrhig ihhvrdhorhhgpdiivggvkhdrohhrghdpghhithhhuhgsrdgtohhmpdegtdhivghtfhdroh hrghdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: 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: <584db921-4c57-4f45-65d6-8273611fd549@informatik.uni-hamburg.de> Date: Thu, 27 May 2021 08:00:28 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 fo= rm of an internet-draft, that describes more precisely what you would li= ke to see happen. On Wed, May 26, 2021, at 18:48, Florian Wilkens wrote: > Dear all, >=20 > first, we want to thank you for your feedback, it is much appreciated!= > We wanted to briefly clarify some details about our idea: >=20 > - AEAD/non-AEAD: completely true. We were mainly looking at ciphers fr= om > 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. >=20 > 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). >=20 > 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 t= he > 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, howev= er > 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 ha= nd > 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. >=20 > 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. >=20 > 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 do= es > not match the WG's opinion that is certainly okay, as we can work with= > current TLS. >=20 > So again thank you for you feedback! > Cheers, > Florian >=20 >=20 > On 17.05.21 18:23, Florian Wilkens wrote: > > Hey folks, > >=20 > > we came across a novel use-case that highlights the need for non-AEA= D > > ciphers in TLS and would like to start a discussion on that. > >=20 > > Our use-case is passive TLS decryption on network monitors (NMs). > > Non-AEAD ciphers would allow to selectively forward the TLS write k= eys > > from clients to a NM that can then passively decrypt TLS sessions, > > without touching their integrity (as the write MAC keys remain on th= e > > host). This would be a major improvement compared to the usage of Mi= tM > > 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 conten= ts. > >=20 > > 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 th= us > > does not interfere with the overall connection security and (ii) is = able > > to selectively decrypt certain TLS connections with the hosts retain= ing > > full authority over the key material. While a MitM proxy can also cl= aim > > 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, ar= e > > forwarded, so that the NM can inspect but not modify TLS packets. > >=20 > > Our prototype is built for the Zeek network monitor [2] and is curre= ntly > > 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 w= e > > built a small prototype) and network monitor (Zeek). > >=20 > > We understand that AEAD ciphers offer many advantages and we underst= and > > the decision to limit the set of available ciphers to secure choices= > > only. However, we think the use-case of passive TLS decryption is hi= ghly > > relevant especially for enterprise settings. In such settings, mainl= y > > MitM proxies are used that are a security problem on their own. > >=20 > > We look forward to your feedback. > >=20 > > Best, > > Florian > >=20 > > [1] https://arxiv.org/abs/2104.09828 > > [2] https://zeek.org > > [3] https://github.com/zeek/zeek/pull/1518 > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > >=20 >=20 >=20 > --=20 > M.Sc. Florian Wilkens > Research Associate > Phone: +49 40 42883 2353 >=20 > IT-Sicherheit und Sicherheitsmanagement (ISS) > Universit=C3=A4t Hamburg > Fachbereich Informatik > Vogt-K=C3=B6lln-Stra=C3=9Fe 30 > 22527 Hamburg > Deutschland >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Attachments: > * OpenPGP_signature