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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 08 July 2017 09:09 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 B2C6013145A for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 02:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.402
X-Spam-Level:
X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 lgD0bykkW5PA for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 02:09:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC8212EA7F for <tls@ietf.org>; Sat, 8 Jul 2017 02:09:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E749ABE2F; Sat, 8 Jul 2017 10:09:16 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyG0TTD91Is4; Sat, 8 Jul 2017 10:09:15 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F9F4BE2C; Sat, 8 Jul 2017 10:09:14 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499504954; bh=pv9n3weNgePUlR7iNBrwD7yt5l+8PSPoCLMj3SCjwG4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=x93br1Pgpc4eRb4eugSqLchU+xGChPddi72C/1BkAI2pC33KsoHM9QF6sFyn5/f7B vG6opVrQSklGcvyKDOhI/GLLiTdc3RsC/vme57oWHxnt/Wz/D9RzQjdC8FRKzAA0Ly nDzByIazgo/5+Cwp2HNSLxuJ/TcMTmDSDBnBSCmw=
To: "Ackermann, Michael" <MAckermann@bcbsm.com>, Watson Ladd <watsonbladd@gmail.com>, Christian Huitema <huitema@huitema.net>
Cc: "tls@ietf.org" <tls@ietf.org>
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> <CACsn0ck8P0Dn3L_tmVmmAez=xo0hmFxQEqkfqw+O7ZzcHpwtTw@mail.gmail.com> <CY4PR14MB13689ABCC728747E9B999AEFD7AB0@CY4PR14MB1368.namprd14.prod.outlook.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <1ab70d05-235e-5a4f-a44b-8b4eadd9ddd8@cs.tcd.ie>
Date: Sat, 8 Jul 2017 10:09:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CY4PR14MB13689ABCC728747E9B999AEFD7AB0@CY4PR14MB1368.namprd14.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QExRDGkt8eQ86aWvBVfDQVAPKXbn7UJ7C"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dOPoo1wWvXXFeVKEmm5Yw9YEcgw>
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 09:09:23 -0000


On 08/07/17 03:06, Ackermann, Michael wrote:
> Converting all session traffic to clear text is not a viable
> alternative for ANY enterprises or industries that I am aware of.  In
> particular those in financial sectors. Security policies, legislation
> and in many cases just good practice would not allow for this. We are
> compelled by these factors to encrypt all data in motion.    But we
> still need to manage our applications, networks, servers and clients.
> Hence the need to decrypt traffic as outlined in this draft.

That assertion of necessity is blatantly false.

It is entirely feasible to decrypt and re-encrypt in many
cases and for that to be efficient and to meet regulatory
needs.

If some systems are so badly designed that doing that while
updating to tls1.3 is a showstopper then that's down to bad
design or other bad practices. Fixing those is the place to
spend effort instead of spending effort on breaking TLS.

Other users of TLS ought not suffer on the basis of such
bad reasoning.

S.


> 
> -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On
> Behalf Of Watson Ladd Sent: Friday, July 7, 2017 9:40 PM To:
> Christian Huitema <huitema@huitema.net>; Cc: tls@ietf.org Subject: Re:
> [TLS] draft-green-tls-static-dh-in-tls13-01
> 
> On Fri, Jul 7, 2017 at 6:10 PM, Christian Huitema
> <huitema@huitema.net>; wrote:
>> 
>> 
>> On 7/7/2017 2:54 PM, Russ Housley wrote:
>>> Stephen: ...
>>>> 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.
>> Russ,
>> 
>> 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?
> 
> The server can send the plaintext to whomever it likes.
> 
> This is the solution enterprises can use today. Nothing can stop that
> from happening. So I don't see why static DH is a) so essentially
> necessary and b) so controversial.
> 
>> From a technical point I prefer using DH shares derived from
> ServerRandom as this avoids certain bugs I've been known to exploit
> from time to time.
> 
>> 
>> -- Christian Huitema
>> 
>> 
>> _______________________________________________ TLS mailing list 
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> -- "Man is born free, but everywhere he is in chains". --Rousseau.
> 
> _______________________________________________ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 
> 
> The information contained in this communication is highly
> confidential and is intended solely for the use of the individual(s)
> to whom this communication is directed. If you are not the intended
> recipient, you are hereby notified that any viewing, copying,
> disclosure or distribution of this information is prohibited. Please
> notify the sender, by electronic mail or telephone, of any unintended
> receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue
> Cross and Blue Shield Association.
> 
> _______________________________________________ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>