" idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge."
Responding ONLY to the above sentence, as I agree with Stephen that this has gotten too NOISY. But at the end of the WG meeting in Prague, the Chairs asked for the two sides to work together to find common ground. We tried very hard to set up as many meetings as we could. Very few would meet with us. Ted Lemon was one. As is evident, Ted and I don't always agree, but he went out of his way to meet with us and exchange views, which was greatly appreciated and the type of effort it will take for two sides that do not agree, to find some form of compromise. The only person that gave us constructive ideas in the common ground, was Martin Thompson, who we all greatly appreciate meeting with us as well. Out of that meeting came the idea that having the client be aware, could address some of the issues brought up in the WG meeting. My point here is that we are trying hard to find ANY common ground and want to work towards this. The client aware feature being added is NOT something that Enterprises want or need, but was an effort to compromise and attempt to gain mutual consensus. And if this is not a feature that everyone wants, then so be it. But at least it was an attempt by a small number of people to try to find common ground and make any form of progress. If we could do more of this and less of the negative, duplicative and sometimes insulting rhetoric on this list, perhaps we can make progress. -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David A. Cooper Sent: Wednesday, October 25, 2017 10:50 AM To: tls@ietf.org Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 This question is based on your that belief that this protocol will "escape" onto the public Internet, that browsers and other clients used by individuals will feel forced to implement it, and that clients will then be forced to enable the extension in order to get through middleboxes that would filter traffic based on whether or not the extension is present in the ClientHello. I've already explained why I believe that scenario will never happen, and so no I do not agree that it is a "fundamental change." The idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge. Obviously you believe that the method being proposed to address one concern introduces another concern. I do not share those concerns for the reasons that I've already stated. I don't plan to comment on this issue any further, and doing so would just be repeating myself, thus just adding to the noise. On 10/25/2017 10:28 AM, Salz, Rich wrote: > ➢ Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not seen by > anyone else *unless* at least one of the two endpoints (client or > server) chooses to provide the contents of the communication to some > other entity. draft-rhrd-tls-tls13-visibility doesn't change that. > > Yes it does. It signals on the wire to any observer that the client and > server agree to this. TLS never attempted to control what the client or > server could do. But it never put any such signal on the wire. This is an > important and fundamental change, and it allows traffic to be categorized and > handled differently. > > Do you agree with that? > _______________________________________________ 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
