From: BITS Security <BITSSecurity@fsroundtable.org>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Industry Concerns about TLS 1.3
Thread-Index: AdIU8WqWM9WBapZoQzyfqxiOaK25fQ==
Date: Thu, 22 Sep 2016 17:19:48 +0000
Message-ID: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [165.117.248.226]
x-ms-office365-filtering-correlation-id: 14de7469-8ae2-4f5b-d4c8-08d3e30ca7b2
x-microsoft-exchange-diagnostics: 1; DM5PR11MB1418;
 6:3M1mHuWVCxB+q+04gIyRQT1UiL7MJBKc67AaA+nrtUBX4necZHpDxrinCHrWwcmSm1aRpat8fVcUHoV4axjZWnj7KRvgG/pURLo07fk4IctW6Y3T8FZij9Eer0em1sFuYmMCUbdIuzGBr23sRTzo4W1d2MA0B+0bCAibprlaJIzrZyKe4PZINV5yGHjOBdZfbQPaTbFBB8RoEiAxuk6euR1NhashuAc8NpsWUUoTnrn2C7mredQWiCD2LTJRqLiYi9lNxujof70lppPaCe7FOx7zDU2rHFsAbvk8aGtFI/NRftPMEPjpiVV6qksmUkVG;
 5:rDqadD5njtd+WKoVQx03e+yZqVbmiU8Wztv2vH52hr60SHs6mvI5n998i4IM3cmkQm39tn585QRjdvwR0mUBLGM6+9Yw1rVhT7D+uB9Sm/FEZ5hcPuB9EX5fLyyCcEjIq6r+1kB+AlnTsGGVzl8xPQ==;
 24:5y4XdvYaGbiON9+6O+RmHQVTOWNw/s37n4R5bgKZW2DNWwBY45LGiND4f3Z6qdrWr2fJBVsocGwUlZdTI3fbiZTzjG0UwweHdZx5eBfWNJA=;
 7:WOlNlpAJYX9BZEHV0jDZsmwEtJUvk3xX8uWbB5kOzXCYFBMXmgjdMFmwX2qNoAyKy+N94LXgYvWLOvAcarqxBTPpyUx/ZfJjNrDh5t9lskMMt0vZNO9zhDQZVI8Hs49Cl8y8TcsNJvFfx1IrGnnGg64AmQlIKL0zSz6tJYNP1W6SGOv1ACAYGCcuOusWKKyRmo1Ys6IUAF9rCgeTPuQKPv823jabrRLtUJ1OSd/4KcW1k2SP6hPceT8U+l85ELaCyKRplmK1JU3tVV+pDO576pkoPmQQidXh41d49LaYtDHAQTpxs8pWpvzJoKq6k3Wx
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR11MB1418;
x-microsoft-antispam-prvs: <DM5PR11MB1418E059D5701CE2E84DFDDEBDC90@DM5PR11MB1418.namprd11.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(192374486261705)(788757137089)(231250463719595)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
 RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6043046)(6042046);
 SRVR:DM5PR11MB1418; BCL:0; PCL:0; RULEID:; SRVR:DM5PR11MB1418; 
x-forefront-prvs: 0073BFEF03
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(6009001)(7916002)(199003)(189002)(101416001)(81166006)(87936001)(8936002)(68736007)(586003)(102836003)(33656002)(19580395003)(2906002)(3660700001)(15975445007)(92566002)(77096005)(3846002)(6116002)(7846002)(81156014)(450100001)(5640700001)(106356001)(76576001)(7736002)(80792005)(555904002)(5002640100001)(110136003)(122556002)(50986999)(97736004)(11100500001)(305945005)(3280700002)(10400500002)(74316002)(551934003)(7696004)(189998001)(5660300001)(2501003)(229853001)(66066001)(105586002)(99286002)(8676002)(9686002)(1730700003)(2900100001)(107886002)(86362001)(54356999)(2351001);
 DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1418;
 H:DM5PR11MB1419.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; 
 A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: fsroundtable.org does not
 designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: fsroundtable.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2016 17:19:48.1288 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 841de5a0-73e8-4cbc-8142-f80b225ef22d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1418
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2ScdPZ8E08RE>
Subject: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 22 Sep 2016 18:27:29 -0000

To:  IETF TLS 1.3 Working Group Members

My name is Andrew Kennedy and I work at BITS, the technology policy divisio=
n of the Financial Services Roundtable (http://www.fsroundtable.org/bits). =
 My organization represents approximately 100 of the top 150 US-based finan=
cial services companies including banks, insurance, consumer finance, and a=
sset management firms. =20

I manage the Technology Cybersecurity Program, a CISO-driven forum to inves=
tigate emerging technologies; integrate capabilities into member operations=
; and advocate member, sector, cross-sector, and private-public collaborati=
on.

While I am aware and on the whole supportive of the significant contributio=
ns to internet security this important working group has made in the last f=
ew years I recently learned of a proposed change that would affect many of =
my organization's member institutions:  the deprecation of RSA key exchange=
.

Deprecation of the RSA key exchange in TLS 1.3 will cause significant probl=
ems for financial institutions, almost all of whom are running TLS internal=
ly and have significant, security-critical investments in out-of-band TLS d=
ecryption.=20
=20
Like many enterprises, financial institutions depend upon the ability to de=
crypt TLS traffic to implement data loss protection, intrusion detection an=
d prevention, malware detection, packet capture and analysis, and DDoS miti=
gation.  Unlike some other businesses, financial institutions also rely upo=
n TLS traffic decryption to implement fraud monitoring and surveillance of =
supervised employees.  The products which support these capabilities will n=
eed to be replaced or substantially redesigned at significant cost and loss=
 of scalability to continue to support the functionality financial institut=
ions and their regulators require.

The impact on supervision will be particularly severe.  Financial instituti=
ons are required by law to store communications of certain employees (inclu=
ding broker/dealers) in a form that ensures that they can be retrieved and =
read in case an investigation into improper behavior is initiated.  The reg=
ulations which require retention of supervised employee communications init=
ially focused on physical and electronic mail, but now extend to many other=
 forms of communication including instant message, social media, and collab=
oration applications.  All of these communications channels are protected u=
sing TLS.

The impact on network diagnostics and troubleshooting will also be serious.=
  TLS decryption of network packet traces is required when troubleshooting =
difficult problems in order to follow a transaction through multiple layers=
 of infrastructure and isolate the fault domain.   The pervasive visibility=
 offered by out-of-band TLS decryption can't be replaced by MITM infrastruc=
ture or by endpoint diagnostics.  The result of losing this TLS visibility =
will be unacceptable outage times as support groups resort to guesswork on =
difficult problems.

Although TLS 1.3 has been designed to meet the evolving security needs of t=
he Internet, it is vital to recognize that TLS is also being run extensivel=
y inside the firewall by private enterprises, particularly those that are h=
eavily regulated.  Furthermore, as more applications move off of the deskto=
p and into web browsers and mobile applications, dependence on TLS is incre=
asing.=20

Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS =
1.2 by major browser vendors, or changes to regulatory standards will force=
 these enterprises - including financial institutions - to upgrade to TLS 1=
.3.  It is vital to financial institutions and to their customers and regul=
ators that these institutions be able to maintain both security and regulat=
ory compliance during and after the transition from TLS 1.2 to TLS 1.3.

At the current time viable TLS 1.3-compliant solutions to problems like DLP=
, NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and monitoring of re=
gulated employee communications appear to be immature or nonexistent.  Ther=
e are serious cost, scalability, and security concerns with all of the curr=
ently proposed alternatives to the existing out-of-band TLS decryption arch=
itecture:=20

-  End point monitoring: This technique does not replace the pervasive netw=
ork visibility that private enterprises will lose without the RSA key excha=
nge.  Ensuring that every endpoint has a monitoring agent installed and fun=
ctioning at all times is vastly more complex than ensuring that a network t=
raffic inspection appliance is present and functioning.  In the case of mon=
itoring of supervised employee communications, moving the monitoring functi=
on to the endpoint raises new security concerns focusing on deliberate circ=
umvention - because in the supervision use case the threat vector is the po=
ssessor of the endpoint.

-  Exporting of ephemeral keys:  This solution has scalability and security=
 problems on large, busy servers where it is not possible to know ahead of =
time which session is going to be the important one.

-  Man-in-the-middle:  This solution adds significant latency, key manageme=
nt complexity, and production risk at each of the needed monitoring layers.

Until the critical concerns surrounding enterprise security, employee super=
vision, and network troubleshooting are addressed as effectively as interne=
t MITM and surveillance threats have been, we, on behalf of our members, ar=
e asking the TLS 1.3 Working Group to delay Last Call until a workable and =
scalable solution is identified and vetted, and ultimately adopted into the=
 standard by the TLS 1.3 Working Group.

Sincerely,

Andrew Kennedy
Senior Program Manager, BITS