On Mar 13, 2018, at 12:37 PM, nalini elkins <nalini.elk...@e-dco.com> wrote: > "We" is a consortium of organizations. I would say over 50 so far. They > operate large data centers. They are in manufacturing, insurance, finance, > and others.
Nalini, why don't you (the consortium) define the standard, then? The reason I ask is that you are essentially asking us (the security folks) to bless something that is pretty obviously a bad idea, and of course we're resisting, and we're going to continue to resist. I don't think you are ever going to get consensus on a document in the IETF that says what you want it to say. And this is perfectly fine. Your consortium can publish its own document that says what you want it to say. Then when this goes badly wrong, it will be your consortium that is responsible, not the IETF. Or if it doesn't go badly wrong, you can claim the credit. But either way, you aren't going to have to keep arguing with us about this. I don't think there's any reason for you to think that the argument is going to end in consensus; this is the reason that some of us are asking for it to stop. Also, if what you produce isn't an IETF standard, then a browser can identify whether it implements IETF tls 1.3, or business-consortium-wtls-1.0. We would hope that browsers that implement the latter would not exist, and that this would be okay for you because you don't actually need this hack in the browser. That's the value of not doing this work in the IETF. Also, I just wanted to mention a problem with something you said earlier: > We feel that there is also an underlying motivation to help the underdog and > protect the political dissident. This is not a correct description of the situation. TLS security is needed by whose information is communiced information over the network when revealing that information to an adversary would put them at risk. When you make TLS security weaker, the set of people who is at risk is everyone, and the risks go from "twitter account compromised" all the way up to "teen with 'shameful secret' commits suicide when outed" or "my aging mom loses her retirement savings." In addition, you are reducing compartmentalization with your keying strategy—in order to make communications easily decryptable, you have to have broadly-shared keys, and that reduces the amount of compartmentalization that TLS can provide between disparate elements in your networks. We have seen the result of poor compartmentalization on network security—the most recent really egregious example being the Equifax, which would have been a lot less bad if Equifax had employed the sort of basic compartmentalization precautions that the NIST recommends. Reducing compartmentalization inevitably makes it easier for an adversary to infiltrate your network and exfiltrate private user data. Maybe it will never happen if you are careful enough. The point is that your characterization of our objections as being about a certain special corner case is simply not an accurate characterization. What you are proposing to do will weaken your network security too, and this weakening is quite likely to result in my personal data being compromised. It would be really great if we could start talking seriously about ways to solve your problem, but that conversation can't take the form "how can we avoid making any changes?" When I've tried to have serious conversations with you and others in your consortium about how to solve this problem in the past, any solution that requires you to implement new technology is always off the table. That's no good.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
