Re: [TLS] TLS@IETF101 Agenda Posted

"Ackermann, Michael" <MAckermann@bcbsm.com> Tue, 13 March 2018 19:21 UTC

Return-Path: <mackermann@bcbsm.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 F1A2612D574 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 12:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com
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 SUjjZS-MK-H8 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 12:20:59 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 1091A12D7F4 for <tls@ietf.org>; Tue, 13 Mar 2018 12:20:59 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 68B62C0DAD for <tls@ietf.org>; Tue, 13 Mar 2018 14:20:58 -0500 (CDT)
Received: from imsva2.bcbsm.com (inetmta04.bcbsm.com [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 3242AC0DA9; Tue, 13 Mar 2018 14:20:57 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DD7BAFE048; Tue, 13 Mar 2018 15:20:56 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 81405FE055; Tue, 13 Mar 2018 15:20:56 -0400 (EDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (unknown [216.32.180.47]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Tue, 13 Mar 2018 15:20:56 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DOHbp2kciO3KPVUWbJOBQUQID2Y/dbhQu7dLoA/0JE4=; b=X+xxUqwbgSJqhnwmeg/SGYWmHu2EQ/DCzdtcM6RCYwZV2xoNSC/X4gW24DSZ47uEKQKq+IgdeYeVbcChVZRAqazBHiC5Tq0uzGieQeGN+09AG4+GG/NjClpKYm2myydER8P4QIuFAGbR2E9BlzroS2x01b/5MtDwmp/DNeOwLtQ=
Received: from BN7PR14MB2369.namprd14.prod.outlook.com (20.176.22.144) by BN7PR14MB2146.namprd14.prod.outlook.com (20.176.21.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 13 Mar 2018 19:20:52 +0000
Received: from BN7PR14MB2369.namprd14.prod.outlook.com ([fe80::b16b:85b4:3e2:e0a2]) by BN7PR14MB2369.namprd14.prod.outlook.com ([fe80::b16b:85b4:3e2:e0a2%13]) with mapi id 15.20.0548.021; Tue, 13 Mar 2018 19:20:52 +0000
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
To: Ted Lemon <mellon@fugue.com>, nalini elkins <nalini.elkins@e-dco.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] TLS@IETF101 Agenda Posted
Thread-Index: AQHTtvl3AKQ0q5ossES5J6XIA/Lf/qPGleQAgABgywCAAXVYgIAACUMAgACBv4CAAEcAAIAFASoAgAAMrwCAAA5/gIAAAfkAgAABAICAAAZagIAAAWsAgAAVGwCAABbqMA==
Date: Tue, 13 Mar 2018 19:20:52 +0000
Message-ID: <BN7PR14MB23696A2767FF9C1A410110AFD7D20@BN7PR14MB2369.namprd14.prod.outlook.com>
References: <6140B7A6-A1C7-44BC-9C65-9BE0D5E1B580@sn3rd.com> <986797a7-81b0-7874-5f39-afe83c86635b@cs.tcd.ie> <CAOgPGoBYc7O+qmjM-ptkRkE6mRsOYgc5O7Wu9pm3drFp3TVa6Q@mail.gmail.com> <d7dfdc1a-2c96-fd88-df1b-3167fe0f804b@cs.tcd.ie> <CAHbuEH7E8MhFcMt2GSngSrGxN=6bU6LD49foPC-mdoUZboH_0Q@mail.gmail.com> <1a024320-c674-6f75-ccc4-d27b75e3d017@nomountain.net> <2ed0gc.p5dcxd.31eoyz-qmf@mercury.scss.tcd.ie> <d7ec110f-2a0b-cf97-94a3-eeb5594d8c24@cs.tcd.ie> <CAAF6GDcaG7nousyQ6wotEg4dW8PFuXi=riH2702eZZn2fwfLQw@mail.gmail.com> <CAPsNn2XCNtqZaQM6Bg8uoMZRJE+qQakEwvw8Cn9fBm-5H+Xn_A@mail.gmail.com> <3F8142DE-EADB-4AB9-A204-7D87ACDCD3E3@akamai.com> <CAPsNn2VE_7+rWT0fp9rrVnZrgcY7ORLWTee+kf_Av1dqm4CiDQ@mail.gmail.com> <CB55AABB-8937-4F6B-B5AC-B6F262F08A4F@akamai.com> <CAPsNn2U_xG28Tumo3oRkQ+6=BHzgv-6YtgNSpwvhdFFRWc7EQQ@mail.gmail.com> <2DC45296-244E-4C72-8B3C-DE47EADAC2DE@fugue.com>
In-Reply-To: <2DC45296-244E-4C72-8B3C-DE47EADAC2DE@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com;
x-originating-ip: [165.225.39.74]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN7PR14MB2146; 7:um9UGF6cnfD88D4QOXRXWnLpXHYOn8Rhc9FN3n/rivcWbHScFq8iKLXoV2OfyK4NXoL1wmOKMXkhDpDqrESe1Egcodkpaa0m7zOJfjFi+zhD+EiHZAjXDzvi96oisDwrv3g6HKEWwBOe391yySTy5YBNsNMVdj5Zjgdyo/I+8ul9hnAhjgdymAmTqY5epWxWGVMmptbS+c4TJ1jmQZozwZFldiqIQvWPlZr8jFZgSNVY5NcAJ1PlLqQJ24iWL6wq; 20:of3XxyOHLsMWOPih70ZyBf1jQxkeIoxKtAd8SdrBa/vMOdszqYtnyrY7PO/0jPal+74MLXrCUjvGPdPAUGqio0NXs6aOzIlSKHyAi77kY8T5IRMCtnrFFmVJkOSLk36vTczxXe3iz4wxaiSo+0dTd/mQtyLzVKcnUuhrR14RQcs=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 22b212c8-5984-4ab9-14b0-08d589178983
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2146;
x-ms-traffictypediagnostic: BN7PR14MB2146:
x-microsoft-antispam-prvs: <BN7PR14MB2146774B1A23061FD4E1A7CBD7D20@BN7PR14MB2146.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(148322886591682)(192374486261705)(131327999870524)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231221)(944501244)(52105095)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:BN7PR14MB2146; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2146;
x-forefront-prvs: 0610D16BBE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(39380400002)(346002)(39860400002)(189003)(199004)(51444003)(14454004)(25786009)(2950100002)(7736002)(81166006)(81156014)(3660700001)(59450400001)(186003)(54896002)(229853002)(106356001)(72206003)(3280700002)(6306002)(26005)(110136005)(53546011)(6506007)(55016002)(33656002)(8676002)(236005)(478600001)(86362001)(93886005)(2900100001)(55236004)(66066001)(102836004)(9686003)(316002)(76176011)(74316002)(5250100002)(97736004)(7696005)(8936002)(4326008)(53936002)(68736007)(790700001)(19609705001)(6116002)(6436002)(2906002)(6246003)(105586002)(80792005)(3846002)(99286004)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR14MB2146; H:BN7PR14MB2369.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: IfK8AYPWxUDtj+z5eG2sm4u7EloPu4sWYBl15mXk1vLlgiR/yE4FmN8sPpUrevJa2fPaiC3dkQpenM4P6MuknL/vpmTQ+EqRdiDbqeHf/jfqwJvs9DjYs+AtjRjRHSeRyC5Ju+h8/oCUARh+KtponRFqQmwHwj9gH1l4p4Kh3FZVoI9Vrys14xyWhPu9PrDazH+o9x/ur537SdTCjGUwjQN48ydgh4aUhyWgg7imj90k5VF+zz8FwYYFGEbaqofZNX2aZoCTVV7mvBnFXjbXGTtqyHLvHVvfLGmCyuYnv00BrjWk85xmeBLZt1DIyzfrSjraA+aGr3SRdzCi9ctQKQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN7PR14MB23696A2767FF9C1A410110AFD7D20BN7PR14MB2369namp_"
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 22b212c8-5984-4ab9-14b0-08d589178983
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2018 19:20:52.6334 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2146
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: 89607dbc-5e0c-4561-97fa-497d34c76326
X-VPM-MSG-ID: 893d3fe6-ef70-4889-900f-b06634db2f44
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JCOZwLLMYJCzJMur7yODlkviEgk>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
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: Tue, 13 Mar 2018 19:21:02 -0000

I think that most Enterprises are not espousing any conversations "how can we avoid making any changes?"
But we would seek to avoid unnecessary,  wholesale, infrastructure architectural changes.
We want to stay with standards wherever/whenever possible and keep the number of standards to the lowest common denominator.
That is why Enterprises are finally coming to the IETF.   Hopeful of some common ground and collaborative solutions.

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Tuesday, March 13, 2018 1:53 PM
To: nalini elkins <nalini.elkins@e-dco.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 12:37 PM, nalini elkins <nalini.elkins@e-dco.com<mailto:nalini.elkins@e-dco.com>> wrote:
"We" is a consortium of organizations.   I would say over 50 so far.  They operate large data centers.   They are in manufacturing, insurance, finance, and others.

Nalini, why don't you (the consortium) define the standard, then?

The reason I ask is that you are essentially asking us (the security folks) to bless something that is pretty obviously a bad idea, and of course we're resisting, and we're going to continue to resist.   I don't think you are ever going to get consensus on a document in the IETF that says what you want it to say.   And this is perfectly fine.   Your consortium can publish its own document that says what you want it to say.

Then when this goes badly wrong, it will be your consortium that is responsible, not the IETF.   Or if it doesn't go badly wrong, you can claim the credit.   But either way, you aren't going to have to keep arguing with us about this.   I don't think there's any reason for you to think that the argument is going to end in consensus; this is the reason that some of us are asking for it to stop.

Also, if what you produce isn't an IETF standard, then a browser can identify whether it implements IETF tls 1.3, or business-consortium-wtls-1.0.   We would hope that browsers that implement the latter would not exist, and that this would be okay for you because you don't actually need this hack in the browser.   That's the value of not doing this work in the IETF.

Also, I just wanted to mention a problem with something you said earlier:

We feel that there is also an underlying motivation to help the underdog and protect the political dissident.

This is not a correct description of the situation.   TLS security is needed by whose information is communiced information over the network when revealing that information to an adversary would put them at risk.   When you make TLS security weaker, the set of people who is at risk is everyone, and the risks go from "twitter account compromised" all the way up to "teen with 'shameful secret' commits suicide when outed" or "my aging mom loses her retirement savings."

In addition, you are reducing compartmentalization with your keying strategy—in order to make communications easily decryptable, you have to have broadly-shared keys, and that reduces the amount of compartmentalization that TLS can provide between disparate elements in your networks.

We have seen the result of poor compartmentalization on network security—the most recent really egregious example being the Equifax, which would have been a lot less bad if Equifax had employed the sort of basic compartmentalization precautions that the NIST recommends.   Reducing compartmentalization inevitably makes it easier for an adversary to infiltrate your network and exfiltrate private user data.   Maybe it will never happen if you are careful enough.

The point is that your characterization of our objections as being about a certain special corner case is simply not an accurate characterization.   What you are proposing to do will weaken your network security too, and this weakening is quite likely to result in my personal data being compromised.

It would be really great if we could start talking seriously about ways to solve your problem, but that conversation can't take the form "how can we avoid making any changes?"   When I've tried to have serious conversations with you and others in your consortium about how to solve this problem in the past, any solution that requires you to implement new technology is always off the table.   That's no good.



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.