Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Russ Housley <housley@vigilsec.com> Sat, 08 July 2017 17:05 UTC

Return-Path: <housley@vigilsec.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 6DA3712EC36 for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 10:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 HkhYNE_dNP7i for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 10:05:07 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEEE1201FA for <tls@ietf.org>; Sat, 8 Jul 2017 10:05:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 681E23004D7 for <tls@ietf.org>; Sat, 8 Jul 2017 13:05:06 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mSc9fDUKF6LV for <tls@ietf.org>; Sat, 8 Jul 2017 13:05:05 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 3C742300429; Sat, 8 Jul 2017 13:05:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net>
Date: Sat, 8 Jul 2017 13:05:03 -0400
Cc: IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <98EB3DAA-DEC7-4D5A-96C4-872A345C7B34@vigilsec.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <CAJU8_nXBFkpncFDy4QFnd6hFpC7oOZn-F1-EuBC2vk3Y6QKq3A@mail.gmail.com> <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie> <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <F830F0DA-F3F1-4A61-8B42-100D31E6F831@vigilsec.com> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie> <E639C60A-D90C-46C2-9A18-5D02D6EBD9E4@vigilsec.com> <d16833ed-3b6b-3685-e109-1673f69c67a5@cs.tcd.ie> <5CF364CB-96E1-4103-9C83-81187897F5F3@vigilsec.com> <4f733022-dabb-53a2-2eb7-425134c137f8@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZBMnyWQEyrbO5EwYxNr_2MnoiVA>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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: Sat, 08 Jul 2017 17:05:08 -0000

>>> And also: I'm sorry to have to say it, but I consider that
>>> attempted weasel wording around the clear intent of 2804. The
>>> clear and real effect if your wiretapping proposal were standardised
>>> by the IETF would be that we'd be standardising ways in which
>>> TLS servers can be compelled into breaking TLS - it'd be a standard
>>> wiretapping API that'd be insisted upon in many places and would
>>> mean significantly degrading TLS (only *the* most important
>>> security protocol we maintain) and the community's perception
>>> of the IETF. It's all a shockingly bad idea.
>> I clearly disagree.  Otherwise, I would not have put any work into the draft.
> 
> What are the specific mechanisms that would allow this technique to be
> used where you
> intend it, i.e. within a data center, and not where Stephen fears it
> would be, i.e., on
> the broad Internet? For example, what mechanism could a client use to
> guarantee
> that this sort of "static DH" intercept could NOT be used against them?
> 

Christian:

In draft-green-tls-static-dh-in-tls13, there is not one.  I have not thought about it in these terms.  The server, if acting in bad faith, can always release the client's traffic.

Russ