On 22/09/16 19:36, Yuhong Bao wrote: > This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
Yuk. Prioritising the needs of those debugging networks over the maybe 5-6 orders of magnitude more folks using them is ass-backwards IMO. That result looks to me like a very bad decision if I'm following it correctly. S. > > ________________________________ > From: TLS <tls-boun...@ietf.org> on behalf of BITS Security > <bitssecur...@fsroundtable.org> > Sent: Thursday, September 22, 2016 10:19:48 AM > To: tls@ietf.org > Subject: [TLS] Industry Concerns about TLS 1.3 > > To: IETF TLS 1.3 Working Group Members > > My name is Andrew Kennedy and I work at BITS, the technology policy division > of the Financial Services Roundtable (http://www.fsroundtable.org/bits). My > organization represents approximately 100 of the top 150 US-based financial > services companies including banks, insurance, consumer finance, and asset > management firms. > > I manage the Technology Cybersecurity Program, a CISO-driven forum to > investigate emerging technologies; integrate capabilities into member > operations; and advocate member, sector, cross-sector, and private-public > collaboration. > > While I am aware and on the whole supportive of the significant contributions > to internet security this important working group has made in the last few > 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 > problems for financial institutions, almost all of whom are running TLS > internally and have significant, security-critical investments in out-of-band > TLS decryption. > > Like many enterprises, financial institutions depend upon the ability to > decrypt TLS traffic to implement data loss protection, intrusion detection > and prevention, malware detection, packet capture and analysis, and DDoS > mitigation. Unlike some other businesses, financial institutions also rely > upon TLS traffic decryption to implement fraud monitoring and surveillance of > supervised employees. The products which support these capabilities will > need to be replaced or substantially redesigned at significant cost and loss > of scalability to continue to support the functionality financial > institutions and their regulators require. > > The impact on supervision will be particularly severe. Financial > institutions are required by law to store communications of certain employees > (including broker/dealers) in a form that ensures that they can be retrieved > and read in case an investigation into improper behavior is initiated. The > regulations which require retention of supervised employee communications > initially focused on physical and electronic mail, but now extend to many > other forms of communication including instant message, social media, and > collaboration applications. All of these communications channels are > protected using 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 > infrastructure 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 the > Internet, it is vital to recognize that TLS is also being run extensively > inside the firewall by private enterprises, particularly those that are > heavily regulated. Furthermore, as more applications move off of the desktop > and into web browsers and mobile applications, dependence on TLS is > increasing. > > 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 regulators > that these institutions be able to maintain both security and regulatory > 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 > regulated employee communications appear to be immature or nonexistent. > There are serious cost, scalability, and security concerns with all of the > currently proposed alternatives to the existing out-of-band TLS decryption > architecture: > > - End point monitoring: This technique does not replace the pervasive > network visibility that private enterprises will lose without the RSA key > exchange. Ensuring that every endpoint has a monitoring agent installed and > functioning at all times is vastly more complex than ensuring that a network > traffic inspection appliance is present and functioning. In the case of > monitoring of supervised employee communications, moving the monitoring > function to the endpoint raises new security concerns focusing on deliberate > circumvention - because in the supervision use case the threat vector is the > possessor 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 management > complexity, and production risk at each of the needed monitoring layers. > > Until the critical concerns surrounding enterprise security, employee > supervision, and network troubleshooting are addressed as effectively as > internet MITM and surveillance threats have been, we, on behalf of our > members, are 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 > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
