If the problem is the use of forward secrecy then there is a simple solution, don't use it. That is, you can, as a server, have a fixed key_share for which the secret exponent becomes the private key exactly as in the RSA case. It does require some careful analysis, though.
But maybe I misunderstood the problem and maybe I should not be putting these surveillance-friendly ideas in people's minds... Hugo On Thu, Sep 22, 2016 at 1:19 PM, BITS Security < bitssecur...@fsroundtable.org> wrote: > 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
