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

Yoav Nir <ynir.ietf@gmail.com> Wed, 19 July 2017 16:02 UTC

Return-Path: <ynir.ietf@gmail.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 76781131686 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 09:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zq6uPyeCWUAg for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 09:02:23 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 81A11127B60 for <tls@ietf.org>; Wed, 19 Jul 2017 09:02:23 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id k71so7013986wrc.2 for <tls@ietf.org>; Wed, 19 Jul 2017 09:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=f9FbvBDtTfyXjQPBQ6l6SF39FeK50sLS6mdtB8akN4I=; b=cJgD1iUD6GQ0OY0RV43WYz/e8kOrW5hf97dOhiYVLtQSHsnhZ5yXaes6GCnro57yKT CPv46LubsE5kmbGVbOFa+cvGyjKKrtqMLfOMzmAcAjoQ5RM+uY3BR5MHcOs9g1J0uy+y 6mpi51emhreFsHrFtdB4GVLGs8pKPuP0ZoRSLV2SZ58IwgxB4YwuhSmbNTkkshTbbCjJ K8DYvI5INisX3JD2ca7w3biFpNua0YD1qhYZ9LKdViu3cszyeumI8r6SBnlIYSs3q+Po rQpwU20+4CCDY9E92gb4RglLMDmNpactsseGP5Yr4m8/o+s/43YQqHsq/zEHgit7XWKf xW5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=f9FbvBDtTfyXjQPBQ6l6SF39FeK50sLS6mdtB8akN4I=; b=tGMu90g+53xL4Xuen2Gzw/Q2qQETyT05rGB0/jq/pz3/d8Xtaoy7cAlr/iEfW79yIA yAVilhAD3uWAvWOaeU4K8z24r0xfYuDkAZwshJFmeNUEckRjwmeg4a1CIyMrxkWfHrps y7SgROgqb1rifdygHVeS3v22ylKbOznm4lIJ5X2GoMssmnDRrj94FNf+22zZN+9xxqX1 SvRHpihG/YFBDY0L4nNmH6XR386De/+Js8KT/4UGkIAEmSCV2qrEYBJ4TC0aobmtnNPx 13exLZ3WpGM7mNk6Jt4mL23/KgyjF/GAnvO9AaqRan2Uh3OzUZg0xLqW38vx2xB+7zj/ elUw==
X-Gm-Message-State: AIVw112+WHVRGNBU5J8lxzYNBg2vQ7qx8derCPGRMphZA/EU8lJcT+cn hxcxFiERGoinMA==
X-Received: by 10.223.131.99 with SMTP id 90mr4358259wrd.155.1500480142032; Wed, 19 Jul 2017 09:02:22 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:71ba:2eb3:367b:d792? ([2001:67c:370:128:71ba:2eb3:367b:d792]) by smtp.gmail.com with ESMTPSA id u66sm908923wrb.77.2017.07.19.09.02.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 09:02:21 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <09CF3C56-E9C7-4F02-8D1F-B5766CC9430C@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7CB3732B-149C-40D5-8827-44CDA12A1349"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 19 Jul 2017 18:02:19 +0200
In-Reply-To: <B2046C73-F081-48F3-BF9F-53C955A4CD28@ll.mit.edu>
Cc: "tls@ietf.org" <tls@ietf.org>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <CAPt1N1mwYyTJVP1AyW0Zu3WBS6SCePAuR97-NQByTQh5Sg6eTA@mail.gmail.com> <CAJU8_nVfKi7iAFxTvVgYVd8G3V-mqMxMXE-03QoXxLSzMcmoHg@mail.gmail.com> <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de> <B2046C73-F081-48F3-BF9F-53C955A4CD28@ll.mit.edu>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YiAUB_rUKuP8T6WFjcO2u2YbNqc>
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: Wed, 19 Jul 2017 16:02:25 -0000

> On 19 Jul 2017, at 17:07, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
> 
>>>> This is exactly right.   We have a real problem here.   We should really solve it.
>>>> We should do the math.   :)
>>> 
>>> Is there appetite to do this work? If we restrict this to two paths, one of which is
>>> spending years designing and implementing a new multi-party security protocol,
>>> the other of which is silently and undetectably (at least on private networks) modifying
>>> the standardized protocol for which lots of well-tested code already exists...
>>> my money is on the latter happening.
>> 
>> There is a good chance that this "cheaper" solution is what will happen.
> 
> Sure. The point is that IETF *must not* support such “undetectable modifications of a standard protocol”.
> The fact that crime invariably happens does not imply that we should become criminals. ;-)
> 
>> However the multi-party protocol may be a safer and better approach and may even
>> forced in by some regulators when it exists as an implemented alternative.
> 
> IETF is supposed to be about designing and (until a decade or so ago) implementing the *right* solutions. In this case multi-party protocol  appears to be “it”.
> 
> So let those who need this capability spearhead the design, with cryptographers and academia helping that work or at least auditing the results.
> 
>>> In every decision we make with respect to the static DH approach, we have to keep
>>> in mind that this change can be implemented unilaterally, i.e., without any modifications
>>> for interop. Consequently, I think the work we really need to do is to design and implement
>>> a FS-breakage detector so we can at least tell when this is happening on the public internet.
> 
> I agree. Though I don’t know off-hand if this is technically possible. Because as you pointed out, an end-point can always choose to leak its part out-of-band, and there’s nothing his communicating peer can do about it (AFAIK). (We can at least make sure that the official implementations such as OpenSSL and GnuTLS do not include such “extensions”.)
> 
> Still, a multi-party protocol that makes the presence or absence of such monitoring explicit, would be the best option, IMHO.

At the very least, a standards-track multi-party protocol like that can be something that standards like PCI, HIPAA and others can latch on to and say “Do TLS 1.3 without backdoors unless you really need to and in that case use *this*”.

That is better guidance than “Do TLS 1.3 without backdoors, unless you really need to and in that case do whatever works for you"