Re: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Martin Thomson <mt@lowentropy.net> Tue, 28 July 2020 07:26 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 A91DA3A0D40; Tue, 28 Jul 2020 00:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=JZ9N25ad; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MbXuatZf
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 PUuLTCxOqI98; Tue, 28 Jul 2020 00:26:12 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBE73A0D30; Tue, 28 Jul 2020 00:26:12 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 0B9751628; Tue, 28 Jul 2020 03:26:09 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 28 Jul 2020 03:26:10 -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 :cc:subject:content-type; s=fm2; bh=n2fOIHwUHzSLiTFr3CADd7WDM7Ym yk5ueapMolELL5k=; b=JZ9N25adl+gZ3sMCANJGTMVpCr1WdAffT4yqsDh5kja0 B37G2eHYW/rbWEOSo1KSNs213qAhQauhoIOewzvo+VPWVMBQvZrbtD+1XClpMzy+ 12KoOsTVZwfjt6+wUBaOVBhkDllw91IKz1wW52YC75lJ81LXK1qL6TjGd4n3NgU9 JyeO5XlaxD6+n6XDMrwr7/XJxo4RGWDCuCq98jWHPdc1ThVt76eHPl+vsXCSlkkB 4ohIOuvVmvXBkreOdRqUCVchbOmgzc7TfbQTfEkmz1+ukVEb7lL14A8f2sBlTdpS ZgOPvZgTZeB1IcszpG7fia5Mlc7Bue+UGFvVjRjeqw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=n2fOIH wUHzSLiTFr3CADd7WDM7Ymyk5ueapMolELL5k=; b=MbXuatZfY4G+1Rov49r3Uj kJ0w//L+ltEc8/c2dGTfpIh1tGFajffhelS5gTJHDRRokjhn1D8cphkWPNqd1qWN I2tAjhCZ1hchCSyL9VG2VJG1XO086Q6JblODVCmho699Emo2gRnIZKga+DTjl6AE 9c/T3WPKXfn+VgLp8Mj5eIVb7fT5+yKEzg69uvu+cD6nldBD0P/DBtXwpfnMBx66 6vMpUxylfK3cx9iFfI/eUp0ZPYSpQEppUr7dRUO4lKPsG6IvR5jhXS0fJPr+EcsQ yrGgenHRwFqWbGtsnb4yTOQyAB9RFvaeux92Wy9F+dOC4a/WdXBa8tjrl+c8iC5Q ==
X-ME-Sender: <xms:EdMfX0aP8HlEDUEmFAsbdo8KY95TBZ_GXGTsIUQ2CYG_7VRtLuLajQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedriedugdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefhiedttdeviefhjeejgf evfeeuudfggfekveekheeugeegleevkeevkedthfeuieenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:EdMfX_YApBwkf3mA6-1s_Rr8rVvW9JGKI7EerfeiKqO2t4Oecv9CyQ> <xmx:EdMfX-_E2bjCdeuC8WdqMKEBEEg-RlYCKwVjXyz2FbptRGbU91shog> <xmx:EdMfX-r_3m4glZIFbspjROLK-u_CB_2F9cyw3vSHTBb8QZHU5kcrpQ> <xmx:EdMfX5EcD-s3l7WK5GptDjkZ16LMtUyqx59oYhw03zqlqhDQlUwfFw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3EEA3E00C1; Tue, 28 Jul 2020 03:26:09 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328
Mime-Version: 1.0
Message-Id: <d9a9ea94-4c4a-40eb-8841-7a92fa31103e@www.fastmail.com>
In-Reply-To: <DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0@DM6PR05MB6348.namprd05.prod.outlook.com>
References: <DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0@DM6PR05MB6348.namprd05.prod.outlook.com>
Date: Tue, 28 Jul 2020 17:25:48 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: "Ron Bonica" <rbonica=40juniper.net@dmarc.ietf.org>, OPSEC <opsec@ietf.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/x7RuUkPUuyZCDJW0RsQnZKr4DlA>
Subject: Re: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp
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, 28 Jul 2020 07:26:15 -0000

On Mon, Jul 20, 2020, at 03:34, Ron Bonica wrote:
> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp 
> <https://datatracker.ietf.org/doc/draft-wang-opsec-tls-proxy-bp/>.

I think that others have said enough about the wisdom of adoption of the approach.  I agree with them, but recognize the right to disagree.

Even if we were to accept that it is a good idea to document best practices for TLS proxying, this document is not currently a good basis for that work.  The introduction is a little deceptive, in that it says that it is about proxying, but there are numerous places in the draft that talk about selective proxying or some amount of forwarding and inspection.  Those practices would require design work.  From what I can infer from the draft, it often assumes the same sort of bad designs that are specifically identified elsewhere as having bad characteristics.

As it is, the draft is not consistent in terms of its approach and scope.  If the goal is to describe pure proxying (a TLS server and a TLS client that intermediate), then it needs a good edit.  If the goal is to describe selective proxying or selective forwarding and modification of TLS messages, then that is a much bigger task.  What are often stated in the draft as requirements around this points are in fact assumptions.  And many of them bad, as others have stated.

--- More detail follows

Intermediaries if this nature are added to effect some sort of centralized control.  This seems to be the primary motivation here also.  If we accept that this is happening, it is important to note the operational effects of that.  Not just on those who have this desire, but on all of those affected.

There is some text about the effect this might have on the ability of clients or servers to introduce new features in Section 4.8.  This is nowhere near sufficient.  By breaking the connection the number of stack layers that are exposed to potential interference, the consequences are not limited to TLS.

Creating negative externalities contributes to TLS interception being despised.  If the intent is to help, then this doesn't go nearly far enough in describing the secondary effects a proxy might cause.


Probably the worst problem is rooted in Section 5.1.  The introduction establishes this as being about proxying, but there are several places that talk about not-proxying sometimes.

Selective non-proxying opens the document up to a whole new set of problems that arise from poor designs for deciding not to proxy.  There is not nearly enough detail here to address this problem properly.  A "good" design for selective TLS proxying does not seem to be the basis of the recommendations.  I'll give a few examples of problems.

>From the Section 4.8 again:

> the TLS proxy MUST conduct proper TLS protocol checks to avoid false identification of TLS handshakes, while taking special care not to contribute to protocol ossification.  

This practice has been directly responsible for more ossification than intermediation, no matter what qualification exists.  

If per-destination not-proxying is required, the proxy can connect to a server, determine that the server is on a non-proxy list, and then complete the handshake with the client (with a caveat regarding ECH here).  I can guess why this doesn't happen (it's expensive and see also Section 5.4), but that doesn't excuse the practice.

The following text from Section 5.3 is deeply problematic:

   A decryption policy decision MAY be made based on the server
   certificate or other trustworthy parameters.  To verify possession of
   private keys that are associated with a particular server
   certificate, the proxy SHOULD complete an out-of-band TLS handshake
   with the same TLS server IP address and TCP port as targeted by the
   TLS client.

It is possible that the authors misunderstand how TLS works, but this check won't work.  Not only because TLS 1.3 encrypts information, but because this is only necessary if the proxy forwards a ClientHello from the client to the server.  At that point, it is too late and the damage has been done (see Andrei's review).


There are a bunch of places where pure proxying - as described in the introduction - is not assumed.  This leads to the same problems already cited.  For instance, in Section 4.2:

> The proxy MAY remove cipher suites from a client-initiated Client Hello message, add new cipher suites, and re-order them in the proxy-initiated Client Hello message.