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

"Ackermann, Michael" <> Sat, 15 July 2017 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64248129AD3 for <>; Sat, 15 Jul 2017 08:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0zbMPGgZnMVH for <>; Sat, 15 Jul 2017 08:36:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3A381287A5 for <>; Sat, 15 Jul 2017 08:36:24 -0700 (PDT)
Received: from (ZixVPM []) by (Proprietary) with SMTP id 18AF0C15E3 for <>; Sat, 15 Jul 2017 10:36:24 -0500 (CDT)
Received: from (unknown []) by (Proprietary) with SMTP id 13ECBC1598; Sat, 15 Jul 2017 10:36:23 -0500 (CDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id C6E8892057; Sat, 15 Jul 2017 11:36:22 -0400 (EDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 7FD1E92053; Sat, 15 Jul 2017 11:36:22 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTPS; Sat, 15 Jul 2017 11:36:22 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Fpisg3Nwi97yUc6gqh1J//LqXZ+PjSDGbeSwzpckRA=; b=Jz133VysMm4wKTDRDHfrBf6JVMH5tlBDpjwtjyAJYINtOuksc7NCjLlI2hKFihWt2Z2RTyecSCqc3Yt8wQPfYf3a2DM0OB8FFwP+bgZRuPb8/X4wtK8ba5T1Hx+pmVurPNShtO998yBNT/MeMRBou7P1kT8HG+EJU4r/h5Xr7ao=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.13; Sat, 15 Jul 2017 15:36:19 +0000
Received: from ([]) by ([]) with mapi id 15.01.1240.022; Sat, 15 Jul 2017 15:36:19 +0000
From: "Ackermann, Michael" <>
To: Ted Lemon <>, "Dobbins, Roland" <>
CC: IETF TLS <>, Matthew Green <>
Thread-Topic: [TLS] draft-green-tls-static-dh-in-tls13-01
Date: Sat, 15 Jul 2017 15:36:19 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: [2602:304:ce75:4b0:1414:401b:871e:f658]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR14MB1368; 20:woSqI2KCHtJseaELPpXXSML71T8T7pXKl9jbXUrMSdH40zuJTGSBL9yoPjy+GDKCOUaLoc/K7vJN+MVBz63nuyiCuY3FfJCEP40JyZ09Xu8wCaWU3rwQuS9ZnH1VHI4c0a09OENSXyMr4MUcqtx47B4O5CYyJ1Fimw8y/9prcj8=
x-ms-office365-filtering-correlation-id: 026a5d75-ffba-4f36-791c-08d4cb973d5b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR14MB1368;
x-ms-traffictypediagnostic: CY4PR14MB1368:
x-exchange-antispam-report-test: UriScan:(151999592597050)(278428928389397)(72170088055959)(26388249023172)(236129657087228)(192374486261705)(48057245064654)(148574349560750)(21748063052155)(247924648384137);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1368; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1368;
x-forefront-prvs: 0369E8196C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39830400002)(39410400002)(51444003)(24454002)(377454003)(7696004)(9686003)(93886004)(3660700001)(53936002)(2906002)(53546010)(7736002)(77096006)(38730400002)(74316002)(229853002)(5660300001)(2900100001)(3280700002)(99286003)(54906002)(14454004)(478600001)(54896002)(6306002)(236005)(33656002)(50986999)(4326008)(8676002)(55016002)(6246003)(39060400002)(54356999)(76176999)(80792005)(19609705001)(2950100002)(189998001)(6436002)(6506006)(790700001)(102836003)(6116002)(230783001)(8936002)(81166006)(72206003)(25786009)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1368;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR14MB136850FD3287DEAD0CD44C78D7A20CY4PR14MB1368namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2017 15:36:19.4737 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1368
X-VPM-GROUP-ID: 59cd3b86-d3f0-4e49-aeff-6122df43a09b
X-VPM-MSG-ID: d3f08915-8f0d-424c-bd64-ee6e79f1c15a
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Jul 2017 15:36:27 -0000

Your first sentence illustrates the disconnect between the Enterprise perspective and what many at IETF are saying.
That being the unencrypted stream is available to the endpoints.   IT IS NOT.     When you run a packet trace at the endpoint,  you will see encrypted payloads and will need the keys to decrypt.
So you can collect packet trace information at thousands or nodes,  or you can collect packet traces from network taps.   You still need the keys to derive meaningful diagnostic and monitoring information.

People than run and manage networks are PAINFULLY aware of this fact.     This is why we need what this draft proposes.

From: TLS [] On Behalf Of Ted Lemon
Sent: Saturday, July 15, 2017 4:06 AM
To: Dobbins, Roland <>
Cc: IETF TLS <>rg>; Matthew Green <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

I think that your first and third points are actually non-sequiturs: the unencrypted stream is available to the entities controlling either endpoint, not just the log.   There is no technical reason that in-flight capture is required to address those two points.

Regarding your second point, this seems to be the real key that is motivating you to make the first and third points.   If I may paraphrase, the problem you are attempting to address is that in some situations two sub-organizations both of which are in principle responsible to a larger organization nonetheless are unable to cooperate due essentially to a failure by one sub-organization to take seriously the responsibilities of the other sub-organization, and the failure of the organization to which they are both subordinate to successfully encourage cooperation on the part of the intransigent sub-organization.   Did I paraphrase that correctly?

On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland <<>> wrote:

> On Jul 15, 2017, at 14:48, Ted Lemon <<>> wrote:
> In the event that it is not feasible for an operator to obtain the plaintext of a message without the key, isn't that because they don't control either endpoint?

First of all, what goes on the wire is often contextually different  (and probatively so) from what's recorded in abstract log files.

Secondly, administrative divisions within a single organization often impede cooperation between those tasked with securing & troubleshooting communications and those who 'own' the assets in question.

Thirdly, for both security & troubleshooting applications, the hard requirement is for real-time visibility & possible intercession, not ex post facto analysis.

Roland Dobbins <<>>

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.