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 

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 

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

Reply via email to