+1, neutrality is appreciated, thank you Sean
Collecting expressed views should prevail in a neutral way, there is no reason
why inappropriate behaviour should be tolerated and let the impression that the
loudest voice is prevailing
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday 23 July 2019 17:52, Bret Jordan <jordan.i...@gmail.com> wrote:
> Thanks Sean.
>
> It is critical that we understand and discuss all sides of an issue and
> address all use cases that market has. Beating people down and trying to
> attack people or their use cases is not something we should be doing in
> formal standards, especially here at the IETF.
>
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can
> not be unscrambled is an egg."
>
>> On Jul 23, 2019, at 4:51 PM, Sean Turner <s...@sn3rd.com> wrote:
>>
>> Tony,
>>
>> While you may have concerns or otherwise disagree with the contents of this
>> draft, let’s please keep discussion on this list, on all issues, polite and
>> professional.
>>
>> spt
>> (as co-chair)
>>
>>> On Jul 23, 2019, at 16:05, Tony Arcieri <basc...@gmail.com> wrote:
>>>
>>> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing)
>>> <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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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
>>>
>>> There is an entire world of network IDS systems beyond middleboxes which
>>> passively decrypt TLS.
>>>
>>> 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.
>>> _______________________________________________
>>> 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
