Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

"Ackermann, Michael" <> Mon, 23 October 2017 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00DCA1399D2 for <>; Mon, 23 Oct 2017 15:09:42 -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_PASS=-0.001, T_DKIM_INVALID=0.01] 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 DThKjIB0UOpt for <>; Mon, 23 Oct 2017 15:09:39 -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 F1C9D139A5A for <>; Mon, 23 Oct 2017 15:09:38 -0700 (PDT)
Received: from (ZixVPM []) by (Proprietary) with SMTP id 0E4AB1C0BBD for <>; Mon, 23 Oct 2017 17:09:38 -0500 (CDT)
Received: from (unknown []) by (Proprietary) with SMTP id 244A41C0A63; Mon, 23 Oct 2017 17:09:37 -0500 (CDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id DCF24FE055; Mon, 23 Oct 2017 18:09:36 -0400 (EDT)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 8B1A5FE04E; Mon, 23 Oct 2017 18:09:36 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTPS; Mon, 23 Oct 2017 18:09:36 -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=ittGJjX5kXtf22uJYfmD/e7LyLi7WjHM6bdEwbCLurY=; b=S72MZX1UQ3Ub+VZkooUZtvzCIt/fCNxte/CJvvmxpeInosoirlsz4WG71O97wAscUhxIm/rbSZOvj8feAF9sxQad0rkw89v3InjsQ/DMWyJTykssC8KXdqMvcySzVW4EH8cWA9hP2KTBa29iSU643e3KPffMymUwGX/QvdOoQx0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Mon, 23 Oct 2017 22:09:35 +0000
Received: from ([]) by ([]) with mapi id 15.20.0077.022; Mon, 23 Oct 2017 22:09:34 +0000
From: "Ackermann, Michael" <>
To: Tony Arcieri <>, Adam Caudill <>
CC: "" <>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Date: Mon, 23 Oct 2017 22:09:34 +0000
Message-ID: <>
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 20:cXvJEKCIEZFD/a4aulalokCVfEybhXdRctciSQbRQzgbr97yE7U8/jfN2sBCkpqJoMNUUVE1OzC3dSlf31UCGHrZC93wBKERpZH+Ne/qo5ugJGOGkgvJQNDN6vVHm1uwXxkAagvzxj0jc6oiYNEH2FZFeY8ZXOyHhHgJErNHnGk=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 39a07e55-1358-479a-0dec-08d51a62be93
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR14MB1365;
x-ms-traffictypediagnostic: CY4PR14MB1365:
x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(21748063052155);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3231020)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR14MB1365;
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(199003)(24454002)(189002)(230783001)(55016002)(97736004)(19609705001)(4326008)(99286003)(3280700002)(53936002)(101416001)(6436002)(66066001)(2950100002)(6306002)(76176999)(39060400002)(50986999)(25786009)(229853002)(6506006)(6116002)(3660700001)(14454004)(54356999)(189998001)(236005)(68736007)(2906002)(77096006)(2900100001)(81156014)(81166006)(8936002)(7696004)(86362001)(5660300001)(105586002)(110136005)(53546010)(93886005)(6246003)(72206003)(9686003)(74316002)(80792005)(54896002)(8676002)(478600001)(106356001)(316002)(3846002)(7736002)(33656002)(102836003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368C52236964E69E1F124FBD7460CY4PR14MB1368namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 22:09:34.8125 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365
X-VPM-GROUP-ID: e34113f8-33fd-4c2d-a6c7-b6716d61ec5e
X-VPM-MSG-ID: de8af55c-2142-4c6d-94bb-dafd4ee263ee
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Mon, 23 Oct 2017 22:09:42 -0000

This can be solved without changes to the protocol or a standardized “backdoor” - and is being done today by at least some enterprises.

Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly disingenuous to cite the need for self-MitM capability as an "industry" concern.

No one I am aware of is pushing for a MitM capability to address this.   In fact it was one of the alternative solutions for which many implementation issues were cited at the Prague meeting and on this list.    But I would like to ask,  what is the solution that your company and others that you reference,  have solved this problem by implementing?

From: TLS [] On Behalf Of Tony Arcieri
Sent: Monday, October 23, 2017 5:43 PM
To: Adam Caudill <>;
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill <<>> wrote:
Those advocating for some standardized method of subverting the security properties of TLS have been offered numerous options in good faith, and continue to reject them all. I’m aware of extremely large enterprises that in fact require TLS 1.2 with PFS, as they made the investment in addressing this issue early on, and do so effectively. This can be solved without changes to the protocol or a standardized “backdoor” - and is being done today by at least some enterprises.

Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly disingenuous to cite the need for self-MitM capability as an "industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find the field divided between those who have invested in a real observability story, and those who think passive network traffic collection is the only way to debug their systems. I think if you were to even take a straw poll of the best approaches monitoring/observability among actual industry practitioners, passive network traffic collection would rank close to the bottom of the list.

I would go as far as to say that if you are among those requesting this misfeature, you are doing a terrible job securing your infrastructure, and should look into modern observability techniques as an alternative to debugging by concentrating network traffic dumps into a single point of compromise which represents a huge security liability. Yes, switching to a new approach to observability is a huge investment that will take time, but so is upgrading to a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM misfeature and could be actively harmed by it, and while a self-MitM capability may be standard operating practice for some, it is not true for all, and identifying those who want the self-MitM capability as "industry" is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF is not listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the rest of us less secure at the request of those who are running insecure infrastructures and apparently intend on keeping things that way.

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.