Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri <[e-mail]>]

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 <
[e-mail]> 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