IETF Logo Mail Archive

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

Roland Zink <roland@zinks.de> Wed, 19 July 2017 14:22 UTC

Return-Path: <roland@zinks.de>
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 79DDA1252BA for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 07:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 k3hZxGc0-Pu1 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 07:22:24 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3C8131D29 for <tls@ietf.org>; Wed, 19 Jul 2017 07:22:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500474141; l=4803; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=oINQj9EhPt9MhTKjwf30Md4Wone8lyQ0x6LdH2aMA6Q=; b=tX3i/PycT25fg/fn4jVgJ/gWzKf4932YogQjN92ZzXTfOxMdyyxjenv6qFMLEelBzH W/QimFGrDfawjDxRT6Kyi6mOZreP/GMH/NahSCLGA0RaDT5VABLFwwFovCYnjJIZtPVH a0/kAbeU68OBgcml1//AreBLfBUo7FSf8gzdk=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWWlmkPDB+7nwYIvSX1sH
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p508A6EE0.dip0.t-ipconnect.de [80.138.110.224]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id Z09c35t6JEML2vS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Wed, 19 Jul 2017 16:22:21 +0200 (CEST)
To: tls@ietf.org
References: <81de2a21-610e-c2b3-d3ff-2fc598170369@akamai.com> <CAPt1N1mwYyTJVP1AyW0Zu3WBS6SCePAuR97-NQByTQh5Sg6eTA@mail.gmail.com> <CAJU8_nVfKi7iAFxTvVgYVd8G3V-mqMxMXE-03QoXxLSzMcmoHg@mail.gmail.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <76bb50c5-a699-4c91-7993-618acb365baf@zinks.de>
Date: Wed, 19 Jul 2017 16:22:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAJU8_nVfKi7iAFxTvVgYVd8G3V-mqMxMXE-03QoXxLSzMcmoHg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F5F27BBFF07A1EB2EC9D8C61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MPMB1XUUDyGMVEi2HxElDcEAnco>
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 14:22:27 -0000


Am 19.07.2017 um 15:51 schrieb Kyle Rose:
> On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon <mellon@fugue.com 
> <mailto: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.
>
There is a good chance that this "cheaper" solution is what will happen. 
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.

> 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
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email