Michael, What, in your message below, has not been said a number of times in this thread? (And countered effectively IMO.) I don't see anything - repeating points already countered is just disruptive noise, sorry.
Thanks, S. On 25/10/17 01:41, Ackermann, Michael wrote: > Excellent points/questions and I just wanted to add that your final example, > regarding hosting providers actually being a MitM, is EXTREMELY prevalent > in Enterprises today and is a management/ monitoring issue specifically > pointed out by Steven Fenter in his presentation to the TLS WG in Prague. > Without the ability to decrypt these sessions our ability to > manage/monitor/secure is severely reduced. > And TLS, being a point to point protocol, cannot help in its current form. > > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David A. Cooper > Sent: Tuesday, October 24, 2017 6:39 PM > To: tls@ietf.org > Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 > > On 10/24/2017 05:18 PM, Salz, Rich wrote: > > > * And, I don't buy the idea that if this extension is standardized that > it will be implemented in commonly-used browsers. > > And that is a risk you are willing for the entire public Internet to take? > > I'm not taking any risk. The ability for a server to allow a third party to > have access to data it is exchanging with a client already exists, and that > ability isn't going away whether this proposal (or something similar) is > standardized or not. As I've already pointed out, for the scenarios people > are concerned about, the "attacks" being described would be much more easily > carried out by some means other than draft-rhrd-tls-tls13-visibility. > > So, no I am not worried about the "risk" of creating a complicated way for > servers and middleboxes to collude to do something that they can already do > now in a simpler way. > > > And what about the fact that it provides a cleartext signal as to whether or > not a client is willing to let itself be MiTM’d, does that bother you? > > No. As I noted before, servers can already allow middleboxes to MiTM > connections with clients with asking the client's permission. Public facing > servers that want to allow this (even if as a result of coercion) won't use > this extension. They'll just enable it without informing the clients. > > There are also other ways a server could allow a middlebox to MiTM the > connections that it has with clients that don't require the client's > cooperation (or knowledge) and that wouldn't require any changes on the > client side; ways that would be easier than trying to use > draft-rhrd-tls-tls13-visibility. > > If the only way (or the easiest way) these connections could be MiTM'd > required getting clients' permission, then this might be a concern, I don't > see servers that want to (or are coerced into) allowing connections to be > MiTM'd asking clients whether they are willing. Given this, we aren't going > to see browsers that are configurable to signal that the client is willing to > "allow" the connection to be MiTM'd. > > I haven't even gotten into the question of what does it mean for a connection > to be MiTM'd. If Company X decides to have its web site operated by Hosting > Provider Y is the connection between the client and Company X being MiTM'd? > The client might think it has a secure end-to-end connection with Company X, > but in reality its data is being intercepted and read by Hosting Provider Y, > without the client's permission (and most likely without the client's > knowledge). How does TLS, currently, prevent this? Why isn't anyone demanding > that TLS cannot be standardized until it can be proven that such a scenario > is impossible? > > > > > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
