+1 ! Well stated. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of nalini elkins Sent: Tuesday, March 13, 2018 11:59 AM To: Colm MacCárthaigh <c...@allcosts.net> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] TLS@IETF101 Agenda Posted
Stephen (and TLS group) We need to look at the bigger picture. The TLS working group has been concentrating on making the Internet secure for the individual user. We feel that there is also an underlying motivation to help the underdog and protect the political dissident. These are all laudable goals. But, the Internet is much more than that. The Internet is the underpinnings of much of the business community which is utilized by consumers (end users). Making a change which makes businesses less secure because crucial functions cannot be done will lead to enormous chaos and disruption. Many businesses are likely to not want to adopt TLS1.3 or seek unique DIY type alternatives. In fact, we have already heard of some planning to block TLS 1.3 traffic just for this reason. So, the main thing to acknowledge is that the enterprise use case is different than the Internet use case. As such, it needs its own solution. Please note that the endpoint is the intended recipient of the session and the owner and responsible party for the security of the data. The presentation in London is to present a use case solution – along with TLS WG recommendations/updates from Prague where half of the room hummed that an internal solution is needed. This rift is not good for the TLS Working Group, it is not good for the IETF, it is not good for the business community and it is not good for the Internet. We need to have some type of methodology so that we can continue to protect ourselves. Therefore, we are asking for WG help with a solution to the enterprise use case. This ID helps explain the situation and subsequent need. If you haven’t had a chance to read it yet, please try to do it before the London meeting. https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/ Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com<http://www.e-dco.com> On Tue, Mar 13, 2018 at 8:06 AM, Colm MacCárthaigh <c...@allcosts.net<mailto:c...@allcosts.net>> wrote: It's my fault for the ambiguous wording, but in this context the quote from me reads as the opposite of my intent. To be more clear: what I meant was that while the proposals aren't making much progress, I don't mind that it's being discussed. I'm happy to have mailing list threads on the topic and agenda time devoted to it (I don't go in person, but I do watch the videos). Since it's an area of such disagreement, I'd prefer to see /more/ discussion, not less. There's always hope of movement and progress on either side, and I think good discourse lessens the risk of dozens of fragmentary DIY solutions, which I think will be the worst kind of outcome of non-engagement. On Tue, Mar 13, 2018 at 10:21 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> wrote: Hiya, Just to be clear: I'm still waiting for the chairs and/or AD to explain how the proposed discussion of this draft is consistent with IETF processes, given the results of the discussion in Prague (a very clear lack of consensus to even work on this topic), and the discussion of the -00 version of this late last year. IOW, I don't consider my objection has been answered. In case people haven't got all the mails from last year at the front of their minds, I went through them for you and have provided links and selected quotes below. Yes, the quotes are selected but I think do indicate that the opposition to these ideas is as before. And there were also the usual voices in support of weakening TLS in this manner as well - a read of the thread clearly indicates to me that discussion of this draft in London will, as before, be a divisive waste of time and energy. Chairs: Please drop the agenda item, or explain how any of this fits our process, because I'm just not getting it. Thanks, Stephen. me, "IMO the WG shouldn't touch this terrible proposal with a bargepole." https://www.ietf.org/mail-archive/web/tls/current/msg24493.html Randy Bush: "there are a lot of us lurkers out here a bit horrified watching this wg go off the rails." (Different thread, but same topic) https://www.ietf.org/mail-archive/web/tls/current/msg24539.html Uri Blumenthal: "+1 to Stephen" https://www.ietf.org/mail-archive/web/tls/current/msg24542.html Rich Salz: "put this on hold for a year or two after TLS 1.3 is done" https://www.ietf.org/mail-archive/web/tls/current/msg24544.html Ion Larranaga Azcue, "I really don't feel confortable with the approach taken in this draft." https://www.ietf.org/mail-archive/web/tls/current/msg24562.html Hubert Kario: "to be clear: me too" (replying about hating the idea) https://www.ietf.org/mail-archive/web/tls/current/msg24578.html Rich Salz: "I am opposed to the basic concept of injecting a third-party into the E2E TLS process." https://www.ietf.org/mail-archive/web/tls/current/msg24585.html Florian Weimer: "I don't understand why this complicated approach is needed." https://www.ietf.org/mail-archive/web/tls/current/msg24607.html Ben Kaduk: "I do not see any potential for a workable solution." https://www.ietf.org/mail-archive/web/tls/current/msg24620.html Uri Blumenthal: "why do we spend time discussing this draft?" https://www.ietf.org/mail-archive/web/tls/current/msg24639.html Christian Huitema: "Maybe they have found ways to manage their applications and servers without breaking TLS..." https://www.ietf.org/mail-archive/web/tls/current/msg24643.html Ted Lemon: "I think we should stop." https://www.ietf.org/mail-archive/web/tls/current/msg24649.html Andrei Popov: "deploying a weakened configuration of TLS 1.3 (without PFS) would not meet the intent of those future mandates/requirements." (On "industry need") https://www.ietf.org/mail-archive/web/tls/current/msg24656.html Ben Kaduk: "The time I am spending on this thread is time that I am not able to spend improving the TLS 1.3 document." https://www.ietf.org/mail-archive/web/tls/current/msg24660.html Dave Garrett: "Please, let's just let this mess die. " https://www.ietf.org/mail-archive/web/tls/current/msg24667.html Uri Blumenthal "I'm against weakening the protocol, since there are other ways to accomplish the perlustrator's mission" https://www.ietf.org/mail-archive/web/tls/current/msg24670.html Yeah, I had to look it up too:-) https://en.oxforddictionaries.com/definition/us/perlustrator Adam Caudill: "To be honest, I’m rather surprised that this group continues to spend time on this." https://www.ietf.org/mail-archive/web/tls/current/msg24712.html Tony Arcieri, "Having worked (and presently working) for more than one company of this nature, in the payments business no less, I would like to restate that it's incredibly disingenuous to cite the need for self-MitM capability as an "industry" concern." https://www.ietf.org/mail-archive/web/tls/current/msg24715.html Colm MacCárthaigh: "I don't have too strong an interest in this thread, it's not going anywhere, and I don't mind that." https://www.ietf.org/mail-archive/web/tls/current/msg24720.html Peter Saint-Andre: "+1 to Stephen's request." (for chairs to close down the discussion) https://www.ietf.org/mail-archive/web/tls/current/msg24734.html Cas Cremers: " I think such a mechanism should not be part of the TLS 1.3 standard." https://www.ietf.org/mail-archive/web/tls/current/msg24885.html Karthikeyan Bhargavan: "I really don’t recommend any change to the TLS 1.3 design to accomplish any of this" https://www.ietf.org/mail-archive/web/tls/current/msg24903.html _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls -- Colm _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com<http://www.e-dco.com> 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
