On Sun, Mar 18, 2018 at 12:09 PM, Darin Pettis <dpp.e...@gmail.com> wrote:
> Agreed. I know a lot of good work has gone into TLS 1.3 and having > visibility to the data once it hits the data center seems like a new > capability to the good folks working that have had TLS 1.3 in mind for the > last couple years. But to enterprises, they have visibility to their data > today and have become dependent on that visibility to utilize security and > troubleshooting tools. > > This actually speaks to the fact the there is a different use case for the > Internet vs the data center. Hopefully we can agree on that point. > We maybe can agree that enterprises feel they have become dependent on their current set of security and troubleshooting tools, which rely on passive decryption for visibility. That doesn't mean that that the enterprise is actually dependent on that current set of tools. > Additionally, bad actors will have the ability to utilize TLS 1.3 > decryption for command and control and data exfiltration purposes. > Security services need to see the data to combat that. > Passive decryption is not necessary to do this. Active decryption/termination can also accomplish this, where all outbound network traffic is required to pass through trusted proxies -- an active approach is necessary anyway to actually stop data from being exfiltrated. Presumably stopping the data is superior to just being able to see it leaving later when looking through forensics. > Finally, I wanted to make the clear that we utilize the term "visibility" > because it is the correct term for the outcome that is needed - regardless > of the technology solution that enables it. > Totally agree, though it's still not obvious why the tools to enable this don't already exist. -- Eric > > Thanks, > Darin > > On Thu, Mar 15, 2018 at 2:50 PM, Ackermann, Michael <mackerm...@bcbsm.com> > wrote: > >> Good point Yoav. >> >> >> >> And this positive side effect holds true in the health care and insurance >> industries as well, and is not an accident. It is one of the primary >> reasons this monitoring is performed. >> >> >> >> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Yoav Nir >> *Sent:* Thursday, March 15, 2018 12:58 AM >> *To:* Rich Salz <rs...@akamai.com> >> *Cc:* tls@ietf.org >> *Subject:* Re: [TLS] Breaking into TLS to protect customers >> >> >> >> Hi, Rich. >> >> >> >> You are conflating customers and users. The customer that may be >> protected by breaking TLS in a bank’s server farm is the bank itself. An >> IPS system with visibility into the traffic may detect bots that are there >> to steal data or mine cryptocurrencies or whatever. >> >> >> >> If the customers of the bank are protected, it’s a happy side effect >> (collateral benefit?). The object is to protect the system integrity and >> the data. >> >> >> >> Yoav >> >> >> >> On 15 Mar 2018, at 5:29, Salz, Rich <rs...@akamai.com> wrote: >> >> >> >> Some on this list have said that they need to break into TLS in order to >> protect customers. >> >> >> >> The thing customers seem to need the most protection is having their >> personal data stolen. It seems to happen with amazing and disappointing >> regularity on astounding scales. Some examples include >> >> · retailer Target, presumably subject to PCI-DSS rules >> >> · Anthem health insurance, presumably a regulated industry >> >> · Equifax, a financial-business organization (but apparently not >> regulated) >> >> · Yahoo, a company created on and by and for the Internet (one >> would think they know better) >> >> We could, of course, go on and on and on. >> >> >> >> NONE of those organizations are using TLS 1.3. >> >> >> >> So what kind of “protect the customer” requires breaking TLS? And what >> benefits and increased protection will customers see? >> >> >> >> >> >> _______________________________________________ >> 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 >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls