Re: [TLS] datacenter TLS decryption as a three-party protocol

Ted Lemon <mellon@fugue.com> Sun, 23 July 2017 19:37 UTC

Return-Path: <mellon@fugue.com>
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 061DB126D46 for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 12:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 n56YqfV60d4I for <tls@ietfa.amsl.com>; Sun, 23 Jul 2017 12:37:14 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B191252BA for <tls@ietf.org>; Sun, 23 Jul 2017 12:37:14 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id d136so46312601qkg.3 for <tls@ietf.org>; Sun, 23 Jul 2017 12:37:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6h7crByhMCCo4MPtkyFOA5tyMW6Umb7h9Fyjsd9nR2Q=; b=zS4MdgPyNSzaMICwVNkkwMqgKSKTXBBOT60M8LOHV8u9pGNjqfS+QuTQc1Jvm9xjff pqIK+0nGS3uIfQu6RlJgqEtFuBkILmLaCfdHIw6ZxzQ+WsFTpojklABr3EML60Zql5Q4 9+oSS2PPBd1REbftV6qyV+Lr16+eeLuuLJ/rEmtpt/IAtWJUhnlrl8MmQ6xtENjeRmwG fRTx4axUeYmLIVr7r/ZeQ5WciQYtbywKrQCJTzmebZvEWbcM8ekHZr2S9C4cKLjYWr0T U1F/WhlCFuXC0wkFyH5z5uTwmSgahuLtJ1jxFJkDLDmO7OAzyLcEc9sFxM2CmsXz7MOg 7mHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6h7crByhMCCo4MPtkyFOA5tyMW6Umb7h9Fyjsd9nR2Q=; b=eUyXwZ7AqqRgAjuGXeGAaXak43DeI6Oe/m9tfbJe0JnhEv5HklLEt17SsSQH6IB1gR n7B7TBE2yLE8+maYUCTVVYz9rLT1nYIJpLDCEibOE8khOY760JVY5yd50Mvyct6ylB4v 8IpKVpTkBM4RVE8ZY8onPgXiZLsgPRqbfGG1I0N15yDmtnCuVRKDZWge3ZVyNUbrrLHP CzbVqQ0NHE/fFDVxS3xTBVCZtqgq5hXXQN+Ydk8ptlfIXnUSam8Oo8EZYB+3fKiuspFS 8d/auYFT9frWoD+Up+n2dY2hwCTAcp8XPTnctlHQ1EziUwZUOw+uHcHB01IeemJwPte/ utXQ==
X-Gm-Message-State: AIVw1129kLYUd3tnuQaef84sX+oDkDnhX1VgzgHDd6gVgfHeGVPGjuXR M/M5l/p2TDNfyxVlxKDrfQ==
X-Received: by 10.55.27.97 with SMTP id b94mr18698292qkb.309.1500838632966; Sun, 23 Jul 2017 12:37:12 -0700 (PDT)
Received: from [10.0.30.114] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 5sm6892006qkk.75.2017.07.23.12.37.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Jul 2017 12:37:12 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-FD2E1DAC-28CA-4F15-A203-6EBFBDAC6FDA"
Mime-Version: 1.0 (1.0)
From: Ted Lemon <mellon@fugue.com>
X-Mailer: iPad Mail (15A5318g)
In-Reply-To: <CE89217F-972F-4F37-B8BA-925AE1FE8D68@ll.mit.edu>
Date: Sun, 23 Jul 2017 15:37:11 -0400
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <44105D6B-4CE0-4C3C-ACFA-30EF1D8AA8F7@fugue.com>
References: <CAAF6GDeFuRy0DN6w3FwmR_nh1G=YBi4+qiEcw0MfSRj4SUCbZQ@mail.gmail.com> <20170720200114.AA2F91A6CB@ld9781.wdf.sap.corp> <06AE85BC-87AD-4CA5-8408-44F670358701@ll.mit.edu> <20170720203238.e66zurx5yn2jja3a@LK-Perkele-VII> <17109486-336E-44C0-B9FC-D65EE14310B5@ll.mit.edu> <20170723070240.x7kmynzmu4jqco5t@LK-Perkele-VII> <C0772D29-CB26-418F-981B-BC2E2435E655@ll.mit.edu> <35FD3356-8300-405A-B8D8-FC2574DB9A56@fugue.com> <CE89217F-972F-4F37-B8BA-925AE1FE8D68@ll.mit.edu>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IyBanmPiaev4g_DMn2IILx83tRY>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 23 Jul 2017 19:37:16 -0000

On Jul 23, 2017, at 12:05 PM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
> I think there's no way the connection can be established if the third party in control of the network does not allow that. 

This is why it’s hard to reason well about this stuff—we tend to get the threat models wrong.   The attack that negotiating enables is not that a third party can block all connections. They can always block all connections.

What the attack enables is blocking only those connections that don’t negotiate a downgrade. So if you negotiate a downgrade, you get to look at your content, but if you don’t negotiate the downgrade, you don’t. This allows a MiTM to coerce end users into negotiating downgrades.

Of course the far end can just not downgrade, but it may have downgrading enabled either for debugging purposes, never intending that all connections be downgraded, or because the operator didn’t configure the server correctly.   If it’s not in the standard, it can still be enabled by operators who are violating the end user’s trust, but won’t happen by accident and won’t be possible to coerce with a MiTM attack.