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

"Ackermann, Michael" <MAckermann@bcbsm.com> Fri, 20 October 2017 16:00 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 16BFD1342CE for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 09:00:16 -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 zmnS-AASUsf0 for <tls@ietfa.amsl.com>; Fri, 20 Oct 2017 09:00:08 -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 7C1DF1342D2 for <tls@ietf.org>; Fri, 20 Oct 2017 09:00:08 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id E28DF1C0AEE for <tls@ietf.org>; Fri, 20 Oct 2017 11:00:07 -0500 (CDT)
Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id E23FD1C0AA8; Fri, 20 Oct 2017 11:00:06 -0500 (CDT)
Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93F6092065; Fri, 20 Oct 2017 12:00:06 -0400 (EDT)
Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 45B8E9206F; Fri, 20 Oct 2017 12:00:06 -0400 (EDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (unknown [216.32.180.16]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Fri, 20 Oct 2017 12:00:06 -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=53Di2Zt+jKGpVSQeSLXhIkhxaOfm1unpriPYCuLud1A=; b=o8wZgp8nXVZNwAi1zTxdrx5mieq/S2jX7Fl+BZeJsVaU6AUviDkwMMo8QWDkUP+eWU3c4v9hkR7tNM1vRhWM1s7MCMaqqlMzj17pWqbsv6f3SV6C2usFX99YFpwewJ+75O/MwO0Ej+qiwhzTeESI/N/iqMgsCypL0+bX8KPWxeE=
Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 20 Oct 2017 16:00:01 +0000
Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.20.0077.022; Fri, 20 Oct 2017 16:00:01 +0000
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
To: "Salz, Rich" <rsalz@akamai.com>, Darin Pettis <dpp.edco@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTO710HVvcnaInjUunozwwxCXv1qLp+S4AgAFTKoCAAAWPgIAAANmAgAABFgCAAAA7gIAAAPWAgAADKICAAALZAIAABTaAgAACs4CAAAEIAIAABEYAgAAZuoCAAAV4gIAAVLoAgAD/VwCAABsIAA==
Date: Fri, 20 Oct 2017 16:00:01 +0000
Message-ID: <CY4PR14MB1368CBA562220D9A3604F0FFD7430@CY4PR14MB1368.namprd14.prod.outlook.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <e8417cc424fe4bf3b240416dfffd807a@venafi.com> <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com> <fd12a8a8c29e4c7f9e9192e1a1d972d6@venafi.com> <D2CAAA44-339E-4B41-BCE0-865C76B50E2F@akamai.com> <d76828f02fc34287a961eba21901247b@venafi.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <c1c0d010293c449481f8751c3b85d6ae@venafi.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <E84889BB-08B3-4A3A-AE3A-687874B16440@akamai.com> <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com>
In-Reply-To: <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.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; CY4PR14MB1365; 20:XNmo6SHLR8S2IyIciiQMMMhExBxtN5x2lIlVGIjAikN/+6ex/xe+SPKfUgIKtdV2mJf5QexbUVYyPdbF8qMRa0aqgYw+szJ/Np3mqnBhPzvfkL4HvAu3NwKa5dQ8Sy5BKQCfAulnO6l776ZoEpkULYEpJ6RrCGp7kmUL317G2zE=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 50a2a135-035e-4e17-ee3a-08d517d39ee3
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:(158342451672863)(278428928389397)(192374486261705)(21748063052155);
x-microsoft-antispam-prvs: <CY4PR14MB13651EB20F5D0CC725043710D7430@CY4PR14MB1365.namprd14.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(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: 0466CA5A45
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(376002)(189002)(199003)(2501003)(105586002)(316002)(53546010)(110136005)(7696004)(86362001)(81156014)(81166006)(74316002)(8936002)(5660300001)(102836003)(6246003)(478600001)(106356001)(7736002)(3846002)(80792005)(93886005)(72206003)(54896002)(8676002)(790700001)(33656002)(9686003)(2950100002)(39060400002)(6306002)(66066001)(25786009)(99286003)(76176999)(229853002)(6506006)(50986999)(6116002)(55016002)(97736004)(53936002)(6436002)(101416001)(3280700002)(189998001)(77096006)(14454004)(236005)(2900100001)(68736007)(2906002)(54356999)(230783001)(3660700001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.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)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR14MB1368CBA562220D9A3604F0FFD7430CY4PR14MB1368namp_"
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 16:00:01.2350 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm01.z120.zixworks.com
X-VPM-GROUP-ID: 4fac1d6d-08bd-4fb2-966c-5e67cb3f3b6f
X-VPM-MSG-ID: 6bb20f90-d663-46ef-875e-dcfb2bb33345
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FsgZy3KsqBQXQrbboDXKpzg7Fr4>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Fri, 20 Oct 2017 16:00:16 -0000

Expressly reacting to the viability of continuing to use TLS1.2 forever.

As a network person,  this sounds a little like suggesting that if we feel there are operational  shortcomings in IPv6,  then we should just plan to stay with IPv4, forever.
And that approach may even be viable for the short term or in isolated situations.
But for the longer term using TLS1.2 is likely to have the following issues for Enterprises:

  *   Industry groups will force us to use newer versions
  *   Policy standards will evolve in similar fashions.
  *   Likely there will be regulatory mandates in many of the marketplaces and business segments that large Enterprises participate in.
  *   Software Products and Applications will attempt to remain current and will eventually sunset support for older protocol versions
  *   Business Partners or Government agency customers may require TLS1.3.
  *   Internal Security Teams may require TLS1.3, at some point in the future.    And they should!    And why should we NOT want  and be able to utilize TLS 1.3 with it’s updated and enhanced capabilities.  We DO WANT THIS!   We just still need to run our networks and businesses and are badly wanting to work with the Working Group to assure our use cases can be accommodated, if at all possible.
  *   And thinking further ahead,  what would be the extended proposed strategy,  when TLS 1.4 (or whatever comes next),  is finalized.        Adopting such a “Stay with the old product forever”  would seem to be tantamount to hoping that TLS 1.3 (and 1.4, etc.),  never get deployed.   For VERY Security focused industries,  such as healthcare and finance,  this is directly opposite of what we want, need and support.   We need security protocols to continue to evolve, improve and become as effective as possible,  but they need to move forward with the understanding  that operational perspectives are important as well.




From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, October 20, 2017 9:44 AM
To: Darin Pettis <dpp.edco@gmail.com<mailto:dpp.edco@gmail.com>>; tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00


  *   The question has been raised: "Why address visibility now?"   The answer is that it is critical that the visibility capability is retained.  It is available today through the RSA key exchange algorithm.  We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real.  That is where the "rhrd" draft has come from.  A way to retain that visibility capability but with a newer and more secure protocol.

You achieve your needs right now by sharing the origin’s RSA key with your debugging agents.  You can achieve the same needs in TLS 1.3 by keeping that architecture, although more information must be shared.  This preserves the architecture and becomes “just” implementation.  This has been brought up before.

The first draft showed how to do this purely on the server side.  Some members of the WG rose up and wanted explicit opt-in. The new draft does that.  In retrospect, it turns out that opt-in is worse, mainly that there is no way to guarantee that this does not “escape” onto the public Internet. This makes sense, if you require opt-in from the client, then it is not surprising that, other entities besides the two parties engaged in the TLS protocol could, well, *require* clients to opt-in.  As I and others have tried to show in email exchangers with Paul, this is a fundamental change to the nature of how TLS is used.

Finally, as has also been mentioned, nobody is preventing you from keeping your servers at TLS 1.2 or earlier.  TLS 1.2 was defined by RFC 5246 in 2008. A decade later, PCI-DSS is only ‘strongly encouraging’ TLS 1.2; the actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will happen any faster?

You have not made your case.



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.