>From the perspective an Enterprise that runs these applications and has
>invested HEAVILY in the debugging networks.........
The reason we are debugging these networks is so that "The 5-6 order of
magnitude of folks using them" will have good service. If they do not, they
will consider competitors and/or generate a litany service calls or complaints.
I.E. When these "Folks" are slow or not working they are just as
unhappy as we are.
-----Original Message-----
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, September 23, 2016 4:06 AM
To: Yuhong Bao <yuhongbao_...@hotmail.com>; BITS Security
<bitssecur...@fsroundtable.org>; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
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
>
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
