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

Kyle Rose <krose@krose.org> Wed, 19 July 2017 13:51 UTC

Return-Path: <krose@krose.org>
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 70159131B44 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 06:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 EM9kKqhuskwX for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 06:51:10 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 C96D512F268 for <tls@ietf.org>; Wed, 19 Jul 2017 06:51:09 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id 32so1781293qtv.1 for <tls@ietf.org>; Wed, 19 Jul 2017 06:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M1Ca05ga+3cWJYU00mE2ZiF8n7Dfv+Z1Auj4Zr88Pxk=; b=nhRcxSRJwdvyQc+hPc5UnULNIPsaVRgQcVe9VVnKwTdLPN79Kmz+h355FcrthdYSRi 0/Bc1Qks7Oy+/GxK0Jp++Q1l3Y6BG+luSN+gPtRiqG//bALGwxh5N04DQFYlGYEGtvBI kXN734/Fo4Fy6c7aik2XEjUgotvYErEfQtJjo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M1Ca05ga+3cWJYU00mE2ZiF8n7Dfv+Z1Auj4Zr88Pxk=; b=TuIfdhAN2w9cL/pSqQLWpV00Q9m02kr9avyGSigndz7gxTwQWmL/LwYrJt7BhBRiqi HndEEB//bo0zrfpTBtX7xivsJDubjbZl/+KHzBdYp0LwwbeVSLVKMqm2HuGuxEmGhlpT HXOLXibDnoOYGZ2/3BEr7G8pM9LB5IG9PsX184A0GHCNz9ODG0ICUU1RXe87q9MFW/NI BGsuCgw7rswx4aS0t4ghQ3QVE3mc+R6Nb5chaoPJqy5WeYlY3oLBVEyXdmOkA2vsXVom AIYYt7RJZm6akskiAeVRsvysIQVApEbOeVOa3qS5W2AVt/tU3vDDEoF+rNPca+fdb4DS 6Iuw==
X-Gm-Message-State: AIVw113cogrMKQqtG3Z1rdrwpdw8CCeAzLjO4EeItLcdCuIM8gg0Nm/E r15wa+pvPe8LNw0AEjLr45D5y8k0kU6z
X-Received: by 10.233.216.1 with SMTP id u1mr239186qkf.10.1500472268738; Wed, 19 Jul 2017 06:51:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.128.194 with HTTP; Wed, 19 Jul 2017 06:51:08 -0700 (PDT)
X-Originating-IP: [2001:67c:1232:144:dcb8:7855:d332:9475]
In-Reply-To: <CAPt1N1mwYyTJVP1AyW0Zu3WBS6SCePAuR97-NQByTQh5Sg6eTA@mail.gmail.com>
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <CAPt1N1mwYyTJVP1AyW0Zu3WBS6SCePAuR97-NQByTQh5Sg6eTA@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 19 Jul 2017 15:51:08 +0200
Message-ID: <CAJU8_nVfKi7iAFxTvVgYVd8G3V-mqMxMXE-03QoXxLSzMcmoHg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c043d4e9304160554abeca4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lq6qxc1FDsQ_CX-u1CEROC7HIYc>
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 13:51:12 -0000

On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon <mellon@fugue.com> 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.

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. Beyond
that, the best we can really do is ask implementors to be polite and
intentionally make their implementations not interoperate silently with TLS
1.3.

Kyle