On 7/23/19 4:05 PM, Tony Arcieri wrote:
On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <ncamw...@cisco..com <mailto:ncamw...@cisco.com>> wrote:

    Hi,

    Thanks to all the feedback provided, we have updated the
    https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04

    draft. At this point, we believe the draft is stable and would
    like to request its publication as an informational draft.


I read this draft as the latest attempt in a disinformation campaign by manufacturers and users of middleboxes that passively decrypt TLS connections to politicize and reframe the argument around what is, at its core, a fundamentally insecure practice which is incompatible with technically sound and highly desirable protocol improvements to TLS.

I implore you stop using overly broad terminology, euphemisms, weasel words, and other deceptive language to argue your points.

I am not a mind-reader, so I will refrain from attributing malice to your choice of words - I would appreciate it if you would extend the same courtesy.

This draft is titled "TLS 1.3 Impact on Network-Based Security", but the subtext is quite clearly the much narrower subfield of middlebox TLS decryption. By using such a grandiose title which is deceptively hiding the true subject matter, you are implying that middleboxes are the sum total of network security.
No such implication is intended - we will look for a more accurate document title.

The draft begins "Enterprises [...] need to defend their information systems from attacks originating from both inside and outside their networks." I am co-owner of a company which heavily leverages firewalls for layer 3/4 network security in conjunction with TLS. We care deeply about network security, and believe that our network is *more secure* specifically because we *don't* perform middlebox interception of TLS.

I consider our company to be in the category of enterprise TLS users, and as an enterprise TLS user who cares deeply about network security, I do not identify whatsoever with the claims this draft is making about the needs of enterprise TLS users as a whole. In as much as what it describes to "network security", it is but one niche consideration within a vastly broader field, and one which is increasingly controversial.

It is indeed controversial, and different enterprises have different views on these. I know this because I regularly interact with a number of these across different industries.

I will point out, since you appear to work at Cisco, that your company works on approaches to network security (e.g. malware detection) which avoid decrypting TLS:

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

I am quite familiar with this. Please note that it does not provide a full replacement for all existing capabilities

There is an entire world of network IDS systems beyond middleboxes which passively decrypt TLS.

Are you saying that it is possible to passively decrypt TLS 1.3 sessions without being a MITM (or otherwise sharing keying material) ?

It is factually inaccurate for this draft to be described as "TLS 1.3 Impact on Network-Based Security". If you are going to write a draft about the impact of TLS 1.3 on middleboxes for passive TLS decryption, please call a spade a spade and don't try to hide your true intentions under a bunch of weasel words and overly broad claims that make it sound like middlebox-related TLS decryption problems are the end of network security as we know it.

My 2c, on behalf of non-middlebox-using enterprise TLS users who feel that attempts by middlebox-using enterprise TLS users to weaken TLS in order to retain compatibility with their traffic decryption appliances is a threat to the security of our enterprise TLS deployments.
Please see my earlier comments on this.

Thanks

-- Flemming


_______________________________________________
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

Reply via email to