This thread blew up rather quickly. Replying on a topic with quotes from various posts, below:
On Saturday, July 08, 2017 05:09:12 am Stephen Farrell wrote: > On 08/07/17 03:06, Ackermann, Michael wrote: > > Converting all session traffic to clear text is not a viable > > alternative for ANY enterprises or industries that I am aware of. Could we please drop the plaintext straw man here? The alternative is building a system that doesn't rely on outdated methods, rather than shoe-horning them into TLS 1.3, not ditching encryption. > > In > > particular those in financial sectors. Security policies, legislation > > and in many cases just good practice would not allow for this. We are > > compelled by these factors to encrypt all data in motion. But we > > still need to manage our applications, networks, servers and clients. > > Hence the need to decrypt traffic as outlined in this draft. > > That assertion of necessity is blatantly false. > > It is entirely feasible to decrypt and re-encrypt in many > cases and for that to be efficient and to meet regulatory > needs. > > If some systems are so badly designed that doing that while > updating to tls1.3 is a showstopper then that's down to bad > design or other bad practices. Fixing those is the place to > spend effort instead of spending effort on breaking TLS. > > Other users of TLS ought not suffer on the basis of such > bad reasoning. +1 It is not the job of the TLS WG to make handling internal requirements of organizations easier with their existing systems in spite of the obvious risks that can be avoided. A drop-in replacement for a theoretically legitimate usecase is also a drop-in replacement for very much illegitimate usecases. Making this a standard is not the way to go here. An argument could be made for informational RFC status rather than standards track, but even then, it's dangerous. On Saturday, July 08, 2017 01:39:43 pm Watson Ladd wrote: > On Sat, Jul 8, 2017 at 10:17 AM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > > Is it bad faith if the server is compelled to enable this > > wiretap interface? For a wiretapper this is a great scheme, > > as they only need to force it to be turned on and accept a > > tiny bit of data and then they can pick up those packets > > from anywhere without having to deal with problems at the > > web server end. So no need to even re-imburse the web server > > for the intercepted access anymore. > > The same applies to static RSA ciphersuites. I understand your desire > to move on with TLS 1.3, but we did burn what seemed to be a somewhat > important usecase to some people, and this draft demonstrates that TLS > 1.3 can be deployed in datacenters without hurting that usecase. As > much as I think enterprise networks are suffering from bad design > decisions that solve problems with boxes and not endpoint changes, > this is a problem people are claiming to face, and there are some > security implications. The organizations that took the easy way at the time now are being told to take a harder way that is more secure. (and are consistently posting to this list with amnesia, acting like we told them to use plaintext) They don't like that; we shouldn't care. We should consider standardizing better solutions for this problem, without regard to how much old systems will have to adapt their design. This has come up on this list MANY times, and each time the end result of discussion was to not revert security decisions made to improve TLS. Releasing a standards track (or even informational) RFC on how to do exactly that using all the old methods, with some tweaks, defeats the purpose of making those security decisions. I'm getting a bit of déjà vu from this thread, and think the same answer should come as from previous threads on the topic: no, please come up with something new. I don't see the proposed document being anywhere close to getting consensus for adoption by the TLS WG. For the stubborn, an (independent) informational RFC would get far less (but nontrivial) opposition. Dave PS Please avoid the "but they'll do whatever they want anyway" comebacks. If the response to not accommodating static keys anymore is to stay with TLS 1.2 forever, then at least they'll be open in their desire to avoid change at all costs. We should not treat this like a hostage scenario. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
