I work in the payments industry, but I am not speaking on behalf of my employer.
I would like to note that if the approaches outlined in the "BITS Security" post are the preferred ones for the companies they represent, those companies have made a huge strategic blunder and should correct those strategic blunders rather than requiring last-minute major design overhauls to TLS 1.3 which would weaken its security. +1000 Kenny Patterson's comments. On Thu, Sep 22, 2016 at 10:19 AM, BITS Security < bitssecur...@fsroundtable.org> wrote: > - 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. > I strongly disagree. Endpoint security is paramount, and some sort of network MitM system is absolutely not a replacement for endpoint agents. I would highly suggest deploying agents on your endpoints. If you don't have endpoint security, all is lost. I would suggest performing multiple security checks regularly on all endpoints throughout your enterprise. Modern endpoint agents can work at a level much higher than TLS network packets (i.e. total memory inspection with kernel-level agents). MitMing traffic in lieu of deploying an endpoint agent only provides monitoring of "compliant" packet streams, which are unlikely to be used by either attackers or insider threats. I'm not saying it's bad to run NIDS or a rolling packet capture system, these are both great, but again, neither are a replacement for an endpoint agent. 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. If you're relying on MitMing S2S traffic for debugging a payment stack, it sounds like your payment stack is opaque to you, which is not only a concern for security, but the general reliable operation of your payment stack as a whole. As a general recommendation, I would suggest building out debugging facilities for your payment stack so you know it actually works, and don't have to lean on crutches like MitMing traffic for debugging purposes. While such a crutch may in the short-term make debugging appear easier, it also assists a patient attacker with internal network access who is passively capturing traffic before attempting to obtain a decryption key which would expose payment credentials e.g. cardholder info/PANs, ACH account numbers, etc. tl;dr: your suggestions would harm the security of more "forward thinking" payments companies. Again, my personal opinion, not that of my employer. -- Tony Arcieri
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
