请选择 进入手机版 | 继续访问电脑版

技术控

    今日:368| 主题:53855
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] Banking industry group requests a way to disable forward secrecy in TLS 1.3

[复制链接]
试着放弃 发表于 2016-10-5 15:00:24
183 4

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
         

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
         

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
         

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
                  

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
                  

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
                  

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
                  

Banking industry group requests a way to disable forward secrecy in TLS 1.3

Banking industry group requests a way to disable forward secrecy in TLS 1.3
                      [  Date Prev ][  Date Next ][  Thread Prev ][  Thread Next ][  Date Index ][  Thread Index ]  Re: [TLS] Industry Concerns about TLS 1.3

  
       
  • To : BITS Security < BITSSecurity at fsroundtable.org >   
  • Subject : Re: [TLS] Industry Concerns about TLS 1.3   
  • From : "Paterson, Kenny" < Kenny.Paterson at rhul.ac.uk >   
  • Date : Thu, 22 Sep 2016 19:14:25 +0000   
  • Accept-language : en-GB, en-US   
  • Archived-at : <https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA>   
  • Authentication-results : ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com   
  • Authentication-results : spf=none (sender IP is ) smtp.mailfrom= Kenny.Paterson at rhul.ac.uk ;   
  • Cc : " tls at ietf.org " < tls at ietf.org >   
  • Delivered-to : tls at ietfa.amsl.com   
  • Dkim-signature : v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gfpScyaUcD3QEW/ob3CFQ68xXrzIgef0Hh+UuL+xmnI=; b=23LLiopSRFSDZVHelMKd0pFphiyRi4St16m7iMkguuIs8tAWkTphtZcF3nscby+4T05N1TjzIR7GcUjbSS0HAehBRL0LmO7Z6mUA4RDeg/x4SY2v6LPyNpdXllldw9NPNLRSU70ypHHCz4Cnkdl6wN9x4bfwdA/bytAhd/9Fox8=   
  • In-reply-to : < [email protected]d.outlook.com >   
  • List-archive : < https://mailarchive.ietf.org/arch/browse/tls/ >   
  • List-help : < mailto:[email protected]?subject=help >   
  • List-id : "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>   
  • List-post : <mailto:[email protected]>   
  • List-subscribe : < https://www.ietf.org/mailman/listinfo/tls >, < mailto:[email protected]?subject=subscribe >   
  • List-unsubscribe : < https://www.ietf.org/mailman/options/tls >, < mailto:[email protected]?subject=unsubscribe >   
  • References : < [email protected]d.outlook.com >   
  • Spamdiagnosticmetadata : NSPM   
  • Spamdiagnosticoutput : 1:99   
  • Thread-index : AdIU8WqWM9WBapZoQzyfqxiOaK25fQAFB4HA   
  • Thread-topic : [TLS] Industry Concerns about TLS 1.3  
  1. Hi Andrew,
  2. My view concerning your request: no.
  3. Rationale: We're trying to build a more secure internet.
  4. Meta-level comment:
  5. You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans.
  6. More exactly, we are at draft 15 and RSA key transport disappeared from the spec about a dozen drafts ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit.
  7. Cheers,
  8. Kenny
  9. > On 22 Sep 2016, at 20:27, BITS Security <BITSSecurity at fsroundtable.org> wrote:
  10. >
  11. > To:  IETF TLS 1.3 Working Group Members
  12. >
  13. > 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.  
  14. >
  15. > 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.
  16. >
  17. > 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.
  18. >
  19. > 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.
  20. >
  21. > 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.
  22. >
  23. > 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.
  24. >
  25. > 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.
  26. >
  27. > 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.
  28. >
  29. > 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.
  30. >
  31. > 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:
  32. >
  33. > -  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.
  34. >
  35. > -  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.
  36. >
  37. > -  Man-in-the-middle:  This solution adds significant latency, key management complexity, and production risk at each of the needed monitoring layers.
  38. >
  39. > 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.
  40. >
  41. > Sincerely,
  42. >
  43. > Andrew Kennedy
  44. > Senior Program Manager, BITS
  45. >
  46. >
  47. >
  48. >
  49. > _______________________________________________
  50. > TLS mailing list
  51. > TLS at ietf.org
  52. > https://www.ietf.org/mailman/listinfo/tls
复制代码

       
  • Follow-Ups :
           
    • Re: [TLS] Industry Concerns about TLS 1.3
              
      • From: Salz, Rich      
           
       
  
       
  • References :
           
    • [TLS] Industry Concerns about TLS 1.3
              
      • From: BITS Security      
           
       
  
       
  • Prev by Date: Re: [TLS] Industry Concerns about TLS 1.3    
  • Next by Date: Re: [TLS] Industry Concerns about TLS 1.3    
  • Previous by thread: Re: [TLS] Industry Concerns about TLS 1.3    
  • Next by thread: Re: [TLS] Industry Concerns about TLS 1.3    
  • Index(es):
           
    •   Date     
    •   Thread   
       
     Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
更多图片 小图 大图
组图打开中,请稍候......



上一篇:KoaHub.js可借助 Babel 编译稳定运行在 Node.js 环境上
下一篇:在 Android 中使用 Java8 的特性
序言述說幸福 发表于 2016-10-5 16:54:44
楼主想办法,让咱的帖子火起来吧。。。。
回复 支持 反对

使用道具 举报

宝贤馨 发表于 2016-10-25 04:37:42
不要和我比懒,我懒得和你比.
回复 支持 反对

使用道具 举报

gbnjjUJHGJFGJHJ 发表于 2016-10-25 05:05:26
贱人永远都是贱人,就算经济危机了,你也贵不了!
回复 支持 反对

使用道具 举报

恏聚恏散 发表于 2016-11-21 06:54:04
我小学十年,中学十二年,我被评为全校最熟悉的面孔,新老师来了都跟我打听学校内幕……
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )

© 2001-2017 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表