Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
I strongly support this work as it represents capabilities that are being developed, deployed and used in practice. It has good intentions and provides a good approach in the context of defense in depth approaches. No security cannot be just on both ends of the communication. One can dream about it but that is not how reality is. Removing this possibility is a limit to the overall defense. I do not understand the reasons behind ignoring reality and the IETF would have, in my naive mind, a strong interest in getting this work under good community adoption so that it is kept in good control with validated best practices. Everyone would win. I support this draft Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday 23 July 2020 03:30, Jen Linkova wrote: > One thing to add here: the chairs would like to hear active and > explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published. > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > rbonica=40juniper@dmarc.ietf.org wrote: > > > Folks, > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. > > Please send comments to op...@ietf.org by August 3, 2020. > > > > Ron > > > > > > Juniper Business Use Only > > > > OPSEC mailing list > > op...@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > -- > > SY, Jen Linkova aka Furry > > 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
Re: [TLS] TLS Impact on Network Security draft updated
+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 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 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 wrote: >>> >>> On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) >>> 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
Re: [TLS] ETSI releases standards for enterprise security and data centre management
I appreciate this answer, thank you Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday 7 December 2018 23:48, Sean Turner wrote: > There is no WG consensus to adopt this draft as no WG adoption call has been > made. draft-dkg-tls-reject-static-dh is an individual draft that is currently > being discussed on this list; in much the same way > draft-green-tls-static-dh-in-tls13 and draft-rhrd-tls-tls13-visibility were > individual drafts that were discussed on this list; there was no WG consensus > to adopt draft-rhrd-tls-tls13-visibility and there was never a call to adopt > draft-green-tls-static-dh-in-tls13. > > The chairs have been debating whether draft-dkg-tls-reject-static-dh is in > scope or whether the discussion should be moved elsewhere. Parts of this > draft we believe are in scope, e.g., providing guidance on handling key share > re-use and pitfalls for not following this guidance. (Note that how to handle > key share re-use is not the same thing as explicitly prohibiting re-use of > keys.) Other parts of the draft contain material for which we did not reach > consensus to address, such as Section 3.3 on prohibiting key-share reuse. We > are not the protocol police and have recently gotten out of that business, > e.g., by removing barriers for cipher suite code points. We do not want to > get back in that business. > > In order to ensure a focused discussion and avoid rehashing the previous > debate regarding draft-rhrd-tls-tls13-visibility, parts of this draft should > be rescoped or removed. Authors are free to take this material to an AD and > seek sponsorship, or to the ISE/IAB for further guidance. > > Cheers, > Joe, Chris, and Sean > > > On Dec 6, 2018, at 21:19, Arnaud.Taddei.IETF > > Arnaud.Taddei.IETF=40protonmail@dmarc.ietf.org wrote: > > I am really surprised how the answers you don't like are systematically put > > on denial. Can you explain me what leads you to think that some people here > > are not concerned by the list of people you list? this is an assumption and > > the wrong assumption. > > Perhaps on the contrary we are concerned BOTH by what these people endure > > but too by what other consistencies are basically removed rights to defend > > themselves. > > As to the marketing aspect frankly this is an invention here and again I > > don't see what allows you to paint the answers you don't like because you > > don't like. > > So I could on the contrary hightight the dogmatism that reins here, with a > > smell of intimidation, and to some degree the sectarianism back to the > > latin roots of the word > > Regarding Human Rights, we DO care about Human Rights too and fact is that > > I had the chance to make more progress in 2 hours than I did in 2 years at > > IET and I had the chance to contribute to a magic moment with a Chinese > > Organization to comply a technical solution to Human Rights requirements. > > You know why? Because we took the time to TALK properly to each other, > > understand each other, learn from each other with no intimidation and no > > wrong assumptions that 'because we LOOK to be on the wrong side' we are > > foolish people, and respect to the fact that not everyone speaks and writes > > a proper English and sometimes words are dangerous when we don't know > > exactly the semantics in the right context > > The assumption that you are the only one who cares is tiresome. > > This group was offered a chance to control the development of a 360 degree > > solution for all parties and it was rejected. Fine. The ETSI took it and is > > taking its responsibly. > > I don't know what leads you to think that a model where security resides > > only on the 2 ends of the communication IS the answer to all the problems. > > The recent continuous scandals that are affecting a number of platforms and > > destroying trust, privacy and security is leading me to think about why > > should I trust this model. By analogy when I see how my body defends itself > > against bad stuff, it is using a battery of models, not one model. > > In any negotiation you can look for what is the right battle, and those who > > understand that point will know that the right battle (and the one which is > > harder for the opposition) is on providing guarantees. This would have been > > a better battle to pick and would have given a chance to work more > > collaboratively and not by confrontation. > > Now I don't understand what leads this group to try now to block the ETSI, > > can someone tell me and in particular the chairs if we have a consensus > > here? > > Fin
Re: [TLS] ETSI releases standards for enterprise security and data centre management
I am really surprised how the answers you don't like are systematically put on denial. Can you explain me what leads you to think that some people here are not concerned by the list of people you list? this is an assumption and the wrong assumption. Perhaps on the contrary we are concerned BOTH by what these people endure but too by what other consistencies are basically removed rights to defend themselves. As to the marketing aspect frankly this is an invention here and again I don't see what allows you to paint the answers you don't like because you don't like. So I could on the contrary hightight the dogmatism that reins here, with a smell of intimidation, and to some degree the sectarianism back to the latin roots of the word Regarding Human Rights, we DO care about Human Rights too and fact is that I had the chance to make more progress in 2 hours than I did in 2 years at IET and I had the chance to contribute to a magic moment with a Chinese Organization to comply a technical solution to Human Rights requirements. You know why? Because we took the time to TALK properly to each other, understand each other, learn from each other with no intimidation and no wrong assumptions that 'because we LOOK to be on the wrong side' we are foolish people, and respect to the fact that not everyone speaks and writes a proper English and sometimes words are dangerous when we don't know exactly the semantics in the right context The assumption that you are the only one who cares is tiresome. This group was offered a chance to control the development of a 360 degree solution for all parties and it was rejected. Fine. The ETSI took it and is taking its responsibly. I don't know what leads you to think that a model where security resides only on the 2 ends of the communication IS the answer to all the problems. The recent continuous scandals that are affecting a number of platforms and destroying trust, privacy and security is leading me to think about why should I trust this model. By analogy when I see how my body defends itself against bad stuff, it is using a battery of models, not one model. In any negotiation you can look for what is the right battle, and those who understand that point will know that the right battle (and the one which is harder for the opposition) is on providing guarantees. This would have been a better battle to pick and would have given a chance to work more collaboratively and not by confrontation. Now I don't understand what leads this group to try now to block the ETSI, can someone tell me and in particular the chairs if we have a consensus here? Finally I am calling on the chairs of this group. It was very interesting to observe the many comments at the last IETF103 about the vile and toxic atmosphere that prevails here. I have all my time to work in these conditions but perhaps the chair could try to think about a more positive atmosphere of work. A bon entendeur salut Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday 5 December 2018 21:36, Daniel Kahn Gillmor wrote: > On Wed 2018-12-05 20:15:08 +0900, Bret Jordan wrote: > > > > On Dec 5, 2018, at 7:33 PM, Stephen Farrell stephen.farr...@cs.tcd.ie > > > wrote: > > > > > > > On 05/12/2018 10:22, Bret Jordan wrote: > > > > I think we should be more open minded and look at the needs from a > > > > 360 degree deployment perspective. > > > > > > I think we should avoid marketing speak. > > > > This is not marketing speak. This is understanding how these solutions > > need to be deployed end to end in all of their scenarios from > > consumer, to small business, to enterprise, to service provider, to > > content provider, to telco, etc. > > Perhaps one of the reasons that this might across as marketing speak to > some people is that your list of "all their scenarios" appears to be > only business use cases (where the individual people involved are at > most consumers of business products). You haven't mentioned > journalists, disk jockeys, activists, flat earthers, dissidents, > students, medical professionals, juggalos, community organizers, gun > nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free > software developers, elected officials, religious minorities, senior > citizens, or any of the other non-business use cases that may depend on > TLS for confidentiality, integrity, authenticity, or any of the other > information security guarantees that are put at risk by proposals like > this. > > One of the concerns the last time we danced this dance was that the > proposal claimed to be interested in one use case only: "the enterprise > data center", and yet offered no meaningful way to effectively limit its > (ab)use outside the data center. This objection was raised clearly, and > the proponents of the protocol change failed to address it. And now it > appears that instead of addressing the concern, they forum-shopped until > they found a place
