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

"Ruslan N. Marchenko" <me@ruff.mobi> Tue, 18 May 2021 06:11 UTC

Return-Path: <me@ruff.mobi>
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 E1F1E3A0045 for <tls@ietfa.amsl.com>; Mon, 17 May 2021 23:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 KVgrJmQ_s7b0 for <tls@ietfa.amsl.com>; Mon, 17 May 2021 23:11:58 -0700 (PDT)
Received: from vex.ruff.mobi (vex.ruff.mobi [IPv6:2a03:4000:6:83fc::a]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069E63A005C for <tls@ietf.org>; Mon, 17 May 2021 23:11:57 -0700 (PDT)
Received: from pi.ruff.mobi (ip-86-49-7-196.net.upcbroadband.cz [86.49.7.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "ruff.mobi", Issuer "R3" (not verified)) by vex.ruff.mobi (Postfix) with ESMTPS id D8426FB3914 for <tls@ietf.org>; Tue, 18 May 2021 08:11:52 +0200 (CEST)
Received: from dei.ruff.mobi (unknown [IPv6:2001:470:741b::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by pi.ruff.mobi (Postfix) with ESMTPSA id 741C210D88 for <tls@ietf.org>; Tue, 18 May 2021 08:11:46 +0200 (CEST)
Message-ID: <51e4b199018129ffa3062f4a552284156198bf09.camel@ruff.mobi>
From: "Ruslan N. Marchenko" <me@ruff.mobi>
To: tls@ietf.org
Date: Tue, 18 May 2021 08:11:42 +0200
In-Reply-To: <CAEMoRCvVxq0LjeUTUpXCF3FgUBYNO_Y2Y-+jnG+B=7vQG0rNdQ@mail.gmail.com>
References: <b084b7a8-80a9-c7d9-fca7-dabb12ad6949@informatik.uni-hamburg.de> <CABcZeBNQRYwyFmwSwnGMXjN-U8UuDHdJCYpg_=YVqfYrRFFByQ@mail.gmail.com> <CAEMoRCuhMPVe=3cT10mgPAjTXNwnsZ2xkiFVL2qtmrbFsz6JVg@mail.gmail.com> <0fc98cd5-ab73-d284-82c3-677a32828fda@cs.tcd.ie> <CAEMoRCvVxq0LjeUTUpXCF3FgUBYNO_Y2Y-+jnG+B=7vQG0rNdQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lY5nbKkLtt2gxvx2004P-ryGBeE>
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: Tue, 18 May 2021 06:12:00 -0000

Am Montag, dem 17.05.2021 um 16:04 -0500 schrieb Darin Pettis:
> Hi Stephen,
> Thanks for the quick reply as I know it is getting late in Ireland. 
> 
> I’m sure you do remember the conversation as you spent a lot of time
> at the microphone around it.  :-)
> 
> It is certainly not an easy question to answer but this group
> comprises the smartest people that I know!!  Surely someone must be
> up for the challenge as fully half of the people in that London hall
> voiced the need for it.  Furthermore, when the day comes that TLS 1.2
> can’t be used anymore, for whatever the reason, this need is going to
> come racing down the tracks…
> 
> So, while everyone is breathing easy right now, it would be great to
> address the need proactively.  
> 

In my eyes the problem (use case) statement is a bit dishonest in this
context. Enterprises need control over data. What this proposal tries
to offer though is snooping/eavesdropping. And control is proxy (mitm)
when you openly and actively control data flow and do not pretend that
you are not here.

In addition to already mentioned integrity leakage via cookie this
proposal also compromises other security (integrity) controls such as
TLS channel binding.

And again it pretends to be opt-in but in the landscape of current
base-line threat-model it's just an invitation to exploit it (send/leak
the keys to malicious party).

Regards,
Ruslan