Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
Stephen, Sorry for the late reply. I was travelling to Montreal from India and was jet lagged. > >> I am thinking the following: >> >> Location: U.S. / Canada (possibly U.K.) >> >> - 3 banks (hopefully from the top 5) >> - 3 large insurance companies (includes back end processing) >> - 3 U.S. federal government agencies >> - 3 companies in the Wall Street / Stock brokerage sector (includes back >> end processing) >> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.) >> - 3 in the retail sector (Home Depot, Target, Lowes, et al) >Those are pretty small numbers unless they're interacting with >a lot of TLS services. It'd be hard to know if they'd be >representative of something or not if they're anonymised in the >results. I would expect that these people would have quite a few applications using TLS. Telnet, FTP, MQSeries, SMTP, and many written by the organization itself. What numbers do you feel WOULD be representative? > I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) It isn't a question of shame but it is just a bit too much information to provide a potential adversary. That is, to say that Stock Exchange XYZ has n% of TLS1.0 clients provides a potential attacker too much information. As I say, most organizations that I know are trying very hard to migrate from older versions. It is not as simple as it might seem. If the organizations need to be identified by name, then I think this will be a show stopper for any kind of data that I might be able to provide. Having said that, I completely understand (and share) your distrust of anonymous data. I am at a loss as to how to proceed. I am open to any constructive suggestions. Thanks, Nalini On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell wrote: > > Hiya, > > On 11/07/18 06:45, nalini elkins wrote: > > Stephen, > > > >> I'd love to add more detail like that and/or more sections for other > > protocols if folks have data to offer with references. > > > > I believe that I can reach out to various people I know. Please comment > > if my methodology is acceptable and if you think this will be helpful. > > It's not whether the methodology is acceptable to me or not > but whether or not the references to the numbers are credible > for readers:-) > > A few comment below, > > > > > I am thinking the following: > > > > Location: U.S. / Canada (possibly U.K.) > > > > - 3 banks (hopefully from the top 5) > > - 3 large insurance companies (includes back end processing) > > - 3 U.S. federal government agencies > > - 3 companies in the Wall Street / Stock brokerage sector (includes back > > end processing) > > - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) > > - 3 in the retail sector (Home Depot, Target, Lowes, et al) > > Those are pretty small numbers unless they're interacting with > a lot of TLS services. It'd be hard to know if they'd be > representative of something or not if they're anonymised in the > results. I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) > > > > > Note: I put in "back end processing" because these are the folks that > most > > often have many connections to other business partners and so in some > ways > > have the most complex systems to deal with. > > > > Note #2: This is aspirational! I hope I can get all these people to > > cooperate. I will try at least to get some in each category. > > > > > > I will ask them the following questions: > > > > 1. How many applications do you have? (This may end up being only the > > mission critical ones as otherwise it may be too hard to obtain.) > > I'm not sure that's so interesting for this question. And I'm not > sure that different people would count things as applications in > the same way. > > > 2. How many are using TLS and how many are still plain text? (We will > > disregard SSH and other such variants.) > > Again, that's not so interesting here. > > > 3. What percent of clients are using a pre-TLS1.2 version? (This will > be > > an estimation. > I don't see why this needs to be estimated, this is kinda the key > measurement needed and easy to measure. There should be no need for > anyone to stick their thumb in the air for this:-) > > It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and > TLSv1.3) and to say for how many TLS sessions or hosts/IPs the > figures apply.
Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
Stephen, > I'd love to add more detail like that and/or more sections for other protocols if folks have data to offer with references. I believe that I can reach out to various people I know. Please comment if my methodology is acceptable and if you think this will be helpful. I am thinking the following: Location: U.S. / Canada (possibly U.K.) - 3 banks (hopefully from the top 5) - 3 large insurance companies (includes back end processing) - 3 U.S. federal government agencies - 3 companies in the Wall Street / Stock brokerage sector (includes back end processing) - 3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.) - 3 in the retail sector (Home Depot, Target, Lowes, et al) Note: I put in "back end processing" because these are the folks that most often have many connections to other business partners and so in some ways have the most complex systems to deal with. Note #2: This is aspirational! I hope I can get all these people to cooperate. I will try at least to get some in each category. I will ask them the following questions: 1. How many applications do you have? (This may end up being only the mission critical ones as otherwise it may be too hard to obtain.) 2. How many are using TLS and how many are still plain text? (We will disregard SSH and other such variants.) 3. What percent of clients are using a pre-TLS1.2 version? (This will be an estimation.) 4. Do you have an active project to migrate off of older versions of TLS? 5. What do you estimate your percent of clients using pre-TLS1.2 versions to be next year? Please let me know if this will be of use & if you have suggestions for improvement. Thanks, Nalini On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell wrote: > > Hi Nalini, > > On 10/07/18 04:50, nalini elkins wrote: > > It would be nice to see some of this reflected in the draft rather than > > only statistics on browsers. The real usage of these protocols is far > > more complex. > > I didn't have time before the I-D cutoff but have since > added a section on mail to the repo pre-01 version. (See > [1] section 3.2.) I'd love to add more detail like that > and/or more sections for other protocols if folks have > data to offer with references. > > Consistent with other folks' numbers sent to the list > yesterday, (though based on a much smaller sat of data I > guess;-) my data shows 10.6% use of TLSv1.0 when talking > SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K > IP addresses that listen on port 25 (mail servers). > > What I don't currently have is a rate of change for that > figure. I think that rate of change is the important number > for figuring out what to do in the next while. E.g. The > WG might conclude that if the percentage of TLSv1.0 is > moving down nicely, we should be a bit patient. If it's > not moving at all, we can probably move now or in 5 years > without that being different. If we're not sure, then get > more data... > > Cheers, > S. > > [1] > https://github.com/sftcd/tls-oldversions-diediedie/blob/mast > er/draft-moriarty-tls-oldversions-diediedie.txt > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt
> discussion. We've received some feedback that has been incorporated > into the working draft and feelers in general have been positive. It > would be good to know if there are any show stoppers that have not > been considered. > > https://github.com/sftcd/tls-oldversions-diediedie > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsftcd%2Ftls-oldversions-diediedie=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215001514=6JSQZe93nWnAELvOgG3KyIcPopQleMDtNF6v8LWFXWU%3D=0> > > Thanks in advance, > Kathleen > > > -- Forwarded message -- > From: > Date: Mon, Jun 18, 2018 at 3:05 PM > Subject: New Version Notification for > draft-moriarty-tls-oldversions-diediedie-00.txt > To: Stephen Farrell , Kathleen Moriarty > > > > > A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt > has been successfully submitted by Stephen Farrell and posted to the > IETF repository. > > Name: draft-moriarty-tls-oldversions-diediedie > Revision: 00 > Title: Deprecating TLSv1.0 and TLSv1.1 > Document date: 2018-06-18 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions- > diediedie-00.txt > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-moriarty-tls-oldversions-diediedie-00.txt=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518=%2BBRGmMbf7r4mXoyWqHmT6kgNjHw7Drh7ldDceG5gqfQ%3D=0> > Status: > https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-moriarty-tls-oldversions-diediedie%2F=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215011518=Qge2nvcx8fz105Uux1rl1eM2yHiI7zbvxA8Pvps10z8%3D=0> > Htmlized: > https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-moriarty-tls-oldversions-diediedie-00=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535=Bz6FrvviPoSIxkB83boGxcOxVg2NvrqS3A1bUinNodc%3D=0> > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moriarty-tls- > oldversions-diediedie > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-moriarty-tls-oldversions-diediedie=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215021535=M1O48yPTPkd%2Bb3%2FE3z0%2FAniBUMozDwfQzp2Ra5sLRbQ%3D=0> > > > Abstract: >This document [if approved] formally deprecates Transport Layer >Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >these documents to the historic state. These versions lack support >for current and recommended cipher suites, and various government and >industry profiiles of applications using TLS now mandate avoiding >these old TLS versions. TLSv1.2 has been the recommended version for >IETF protocols since 2008, providing sufficient time to transition >away from older versions. Products having to support older versions >increase the attack surface unnecessarily and increase opportunities >for misconfigurations. Supporting these older versions also requires >additional effort for library and product maintenance. > >This document updates the backward compatibility sections of TLS RFCs >[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This >document also updates RFC 7525. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215031539=ixEPAZe51d1FhvdB9sQ8mzRHY04Blyx%2BIYjlFC%2Fo0dw%3D=0> > . > > The IETF Secretariat > > > > -- > > Best regards, > Kathleen > > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7CAndrei.Popov%40microsoft.com%7C30b7cfd6c111409f442b08d5e5bd3777%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636667523215041552=GkIXrs3zVeUBaEU2EUL8%2FXJdDdkDUlQ70iKr0rDJQRU%3D=0> > > > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI
>So-called "Enterprise" infrastructure has delayed the work of this group >for at least a year. Noone of the people creating that mess has reached >out to this group to explain why they constantly break TLS - let alone >apologize for it. >I believe there's a large overlap of the actors breaking TLS with the >actors who are worried about things like SNI encryption. I'm not sure I >see any reason not to consider these actors as anything but opposed to >the work of this group. I believe that enterprise people have tried over and over again to explain. You may wish to take a serious look at: https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/ I, personally, have tremendous respect for the people in the TLS group. The level of cryptographic expertise as well as the passion / commitment is unparalleled. I think both "sides" are acting with good intentions - while looking at the world through their own lenses. Enterprises need to be able to do Business As Usual (BAU) while integrating innovation into their networks. I suspect that no one likes middleboxes or "breaking" TLS but it is at least temporarily necessary. You cannot hide your head in the sand and pretend it does not exist. Markets exist for a reason. People do not spend time and money to make presentations (at the TLS group) without having a very good reason to do so. IMHO, having everything at the end points (or the end-to-end principle) has led to an unsustainable trajectory to expensive and complex network functions and end-points. I have done a rudimentary survey of some of the enterprises I know and they say that much (if not most) of their time is spent in patching applications and end points. This is one reason they cannot look ahead to bigger tasks like migrating to IPv6. I completely agree that enterprises have not presented the statistics and a carefully reasoned study to substantiate the above claims. I am in the process of taking a step back to see what we need to do - what drafts we need to write and what numbers we need to present - to have a full picture of how Internet protocols are used. Enterprises are a very large group of users of the Internet protocols and need to be considered as such. Nalini On Wed, Jul 4, 2018 at 1:54 AM, Hanno Böck wrote: > So-called "Enterprise" infrastructure has delayed the work of this group > for at least a year. Noone of the people creating that mess has reached > out to this group to explain why they constantly break TLS - let alone > apologize for it. > > I believe there's a large overlap of the actors breaking TLS with the > actors who are worried about things like SNI encryption. I'm not sure I > see any reason not to consider these actors as anything but opposed to > the work of this group. > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS to protect customers
> Are we going to discuss draft-fenter ad hoc, or we'll start a new thread dedicated to that? Because I strongly believe I also have some suggestions for that draft. Artyom, yes, as far as I am concerned at least, please start a new thread. Sorry I am getting behind on responding to all the emails. But, I am very interested in what you have to say. I just can't keep up. Will do my best to respond as promptly as possible but there are many of you and not so many of me. Nalini On Thu, Mar 15, 2018 at 3:33 AM, Artyom Gavrichenkov <xima...@gmail.com> wrote: > Are we going to discuss draft-fenter ad hoc, or we'll start a new thread > dedicated to that? Because I strongly believe I also have some suggestions > for that draft. > > ср, 14 мар. 2018 г., 23:30 Salz, Rich <rs...@akamai.com>: > >> Some on this list have said that they need to break into TLS in order to >> protect customers. >> >> >> >> The thing customers seem to need the most protection is having their >> personal data stolen. It seems to happen with amazing and disappointing >> regularity on astounding scales. Some examples include >> >>- retailer Target, presumably subject to PCI-DSS rules >>- Anthem health insurance, presumably a regulated industry >>- Equifax, a financial-business organization (but apparently not >>regulated) >>- Yahoo, a company created on and by and for the Internet (one would >>think they know better) >> >> We could, of course, go on and on and on. >> >> >> >> NONE of those organizations are using TLS 1.3. >> >> >> >> So what kind of “protect the customer” requires breaking TLS? And what >> benefits and increased protection will customers see? >> >> >> >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
On 15/03/18 00:05, nalini elkins wrote: >> There is no question of a smokey back room. >I'm sorry to disagree so bluntly, but while I was an >AD some of the people involved here requested that I >meet them in private to discuss this topic before it >had been raised on the list, and without telling me >ahead of time who, from what "enterprises," would be >in the room looking for what. As an AD I was always >happy to meet folks and have quiet discussions about >how to engage with the IETF or explore some detail of >how to get something done, I definitely did draw a >line well before private meetings aiming to overthrow >established WG consensus. >While that all might be put down to a tactical error >in which advice to follow with whom when initially >engaging with the IETF, from my POV it was the epitome >of a request for a smokey-back room discussion. >So yes, I do find that there are questions here about >smokey back rooms indeed. 1. With respect, I contend that you are conflating what happened then with what I am suggesting now. 2. Also, your description of what happened then does not match with my memory. We may have an honest disagreement or recollection of events. I believe I have the original email chain somewhere & can try to find it, if necessary. My version of the events is: 1. A couple of years ago, I was involved with some "enterprises" who felt they had an issue with the upcoming TLS1.3 standard. In particular, the deprecation of RSA. 2. They were concerned about the reputational risk to their company of speaking in a public forum. (This is a huge issue for many companies.) Also, they were not used to writing Internet Drafts or presenting at an IETF group. 3. I had no experience with such a situation so I was not sure what to do either. My own work is in IPPM (if anyone is interested, you can look at my work in RFC8250), so I was not involved with the TLS group very much either. (A situation which has since been corrected. I now am happy to know many of you quite well.) (Still no claims to being a crypto expert, though!) I asked a former Chair of the IETF for advice. He suggested asking for a session with the leadership of the TLS group under Chatham House rules. I did so. As I recall, I asked to have a discussion of the issues to see what we should do. I never asked for any consensus of the WG to be overturned. I may be a dim bulb but I am not a complete idiot. I do have some idea of how things work as far as WG consensus. Again, as I recall, you replied at some length about "subverting the process". After a few more somewhat emotional emails back and forth, where I was not able to convey my point adequately or to reach an understanding, I gave up on that route. It is completely possible that I did not ask correctly or convey the right information. It was a new situation to me & as I say, I was not sure what to do. I did my best. If needed, I can look for the original email chain. 4. Then, I went back to these "enterprises". They had to go all the way to the CEO of their company to get authority to speak publicly. They did so at the Chicago IETF. And, you know what, I am going to do everything I can to help these guys. They have a point of view that deserves to be represented. They have put in a huge amount of time and effort to try to present what they feel will be a real problem for their company. They are not doing it for any other reason. Again, they are not used to writing Internet drafts. And, I am not as much as help as I could be to them in writing drafts for TLS as that is not where I live, so to speak. If this was an issue in performance metrics, I could write the drafts for them. But, this is TLS, so we have to get others to help. We have tried as much as we can to follow the process. We are all imperfect, we are doing our best. 5. This issue with people being able to speak publicly is real. It needs to be recognized. Not everyone works for an academic institution or companies which support speaking openly about network architecture issues. Even some of the network product vendors who are starting to speak openly on this issue have had to talk to their CEOs before commenting. Not everyone will go to such lengths. They will mostly just give up. Which is unfortunate for everyone. Including the IETF. I completely understand why deliberations of something as important as TLS need to be public and in the open. I support that. I am just saying that there is an important constituency for whom speaking in an open forum is a real issue. Frankly, this is why we formed the "consortium". Nalini On Wed, Mar 14, 2018 at 5:13 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > On 15/03/18 00:05, nalini elkins wrote: > > There is no question of a smokey back room. > > I'm sorry to disa
Re: [TLS] TLS@IETF101 Agenda Posted
Stephen, More on other points later. I am getting pretty tired as am jet lagged. >I am just fine with talking openly on the mailing list, as >per IETF processes. I see no benefit in smokey back room >discussions here at all, and only downsides to such. You know, this issue of side or quiet conversations keeps coming up. Let me try to clarify what I feel is a misunderstanding. In other WGs, we talk to each other sometimes in small groups, sometimes one to one to try to clarify things. The result ends up in the draft or the public email list, as appropriate. There is no question of a smokey back room. I remember a while back when I had a lengthy disagreement with someone which kept not getting resolved, someone (actually, Al Morton - dear sweet guy!) took me by the scruff of the neck and made the two of us sit down together with him. In half an hour, we resolved the point and were able to continue with the draft. If we had kept throwing things at each other, as it is easy to do via email, who knows how long the conflict would have lasted. I learned a valuable lesson that day. So, I am not trying to subvert the process as some seem to imply. Talking to each other f2f actually seems to me to be one of the points of journeying quite so far and spending so much money to come to an IETF meeting. (Having said that, the "journeying so far part" or plane trip is catching up with me! More tomorrow.) Nalini On Wed, Mar 14, 2018 at 4:49 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > On 14/03/18 23:32, nalini elkins wrote: > > But, it is a very difficult issue. If I can use a different analogy, if > > the City of Monterey built a new sewer system and told me that to connect > > to it, I had to build a new house, I would scream! > > Analogies cannot be used to draw conclusions, merely to illustrate. > That analogy doesn't help illustrate anything for me fwiw. > > > TLS is used in many, many places. The Internet is critical to the > > businesses of the world. > > Yes. Both fine reasons to not mess about with, weaken or > try break the TLS protocol. > > BTW - while you and others may constantly over-claim and > say your consortium represents "enterprises," I assume you > do not claim to represent all "business." ;-) > > > You can't just say use something other than > > TLS. > > Yes. I can. Kerberos and IPsec are used within many enterprise > networks. TLS is not the only tool in the toolbox. > > If your consortium want a multi-party security protocol that > does not affect other folks' security as you seem to claim, > then that is the obvious route to explore. And that protocol > needs to be non-interoperable with TLS (maybe even non-confusable > in some stronger sense) IMO in order to avoid the risks that > breaking TLS would result in us all taking. > > > Or don't use the Internet. It's not so easy. > > I never said that. Why invent something like that? > > > I wish we could actually talk to each other quietly and reasonably. This > > is a very, very difficult problem. > > I am just fine with talking openly on the mailing list, as > per IETF processes. I see no benefit in smokey back room > discussions here at all, and only downsides to such. > > S. > > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
>>Enterprises value security and privacy. They have a different job to do. What they are trying to do is to protect against leakage of data, do fraud monitoring, protect against malware and many other things. When this gets into the medical arena, >>it can even be lives. I don't even see how you can say what you are saying. >>Let me ask you then, what are the use cases you find to be valid? Saying that enterprises don't value security and privacy is really not terribly useful to resolving any discussion. > Isn't it the core of the discussion though? I think the core of the discussion is that no matter how many times I say that enterprises are trying to protect their customers, you do not consider that a valid use case. It is not possible to discuss something when the other person does not think you have a valid point of view. Nalini On Wed, Mar 14, 2018 at 4:30 PM, Ryan Sleevi <ryan-ietf...@sleevi.com> wrote: > > > On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins <nalini.elk...@e-dco.com> > wrote: > >> >>>- > Nalini, why don't you (the consortium) define the standard, then? >>> >>> >>> >>> > Indeed, if a “TLS13-visibility” standard has to be defined, it would >>> make sense for the consortium (rather than the TLS WG) to define it. >>> >>> >>> >>> I completely disagree. Here is why I would not prefer that route: >>> >>> >>> >>> 1. Multiple standards are likely to diverge. >>> >>> >>> Take the case of India, we have over 700 dialects. Many of them started >>> with the same root language. It has gotten so villages 10 miles apart >>> cannot talk to each other. We use English (a clearly non-native language!) >>> to communicate. >>> >>> >>> I could see the same happening with TLS and Consortium-TLS. Not a >>> happy thought for interoperability. >>> >> >> >Why is there any need for interoperability between TLS and >> Consortium-TLS? TLS is designed to be secure and reliable, and it's clear >> that Consortium-TLS finds such goals problematic. Yet I fail to see why >> that's a problem, since the claimed goal >is that Consortium-TLS would only >> be used within a single enterprise/datacenter, and thus would never need to >> interoperate with a world that valued security and privacy. >> >> >> Enterprises value security and privacy. They have a different job to >> do. What they are trying to do is to protect against leakage of data, do >> fraud monitoring, protect against malware and many other things. When >> this gets into the medical arena, it can even be lives. I don't even see >> how you can say what you are saying. >> >> Let me ask you then, what are the use cases you find to be valid? Saying >> that enterprises don't value security and privacy is really not terribly >> useful to resolving any discussion. >> > > Isn't it the core of the discussion though? Whether the enterprise case - > which understandably and fundamentally weakens the security assurances, > both to servers and to clients - is justified, given the ecosystem risk it > poses? And the specific proposals, as demonstrated, have negative impacts > both in the design and deployment of TLS. > > Given that, and given the ample discussion on-list motivating PFS, and > given the stated reasoning, it doesn't seem that "inter-protocol > interoperability" is necessary nor desirable. It's true that enterprises > don't value the same security and privacy properties that have been > discussed on the list - we wouldn't be having this discussion if that was > not the case. This isn't unproductive or not useful - this is based on the > statements from those advocating for the weakening of security of the > protocol. > > As such, the need for interoperability is not a goal that's supported by > the discussion to date, and thus the concerns - that TLS and consortium-TLS > would diverge - does not seem supported by the arguments. So I do hope you > can answer - why is interoperability between TLS and Consortium-TLS > necessary, given that the use cases to date of Consortium-TLS state they'll > be limited to the enterprise or datacenter, for which the only > interoperability concerns that arise are between devices supporting > Consortium-TLS, which by speccing in a Consortium as suggested, you could > resolve? > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
- >The simple explanation is that people think they will have serious issues with TLS1.3 and actually, TLS1.2 when it is DH only. >They have a problem with a protocol that doesn’t use static-RSA key exchange. And they would rather not pay for a solution to that problem. I would not agree with that. People understand that sometimes they have to pay when there are protocol and other changes. It is a question of if you could do everything that you needed to do to protect your customers even if you re-built your network from the ground up. Nalini On Wed, Mar 14, 2018 at 4:33 PM, Salz, Rich <rs...@akamai.com> wrote: > >- The simple explanation is that people think they will have serious >issues with TLS1.3 and actually, TLS1.2 when it is DH only. > > > > > > They have a problem with a protocol that doesn’t use static-RSA key > exchange. And they would rather not pay for a solution to that problem. > > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
Stephen, >So it doesn't really help the discussion to claim that >such-and-such a (set of person(s) is/are good actors - we do >assume that, but also that there are others who would like >the same changes to happen who do not share the IETF's goals >of making Internet security better as far as we can. You know, I actually find myself in agreement with some of your points (not all!) I lived for a number of years in a country which was a military dictatorship with no freedom of speech. I am well aware of what some people who want to hang on to power at all costs and place no value on human life are prepared to do to others. And, their power can be multiplied and further weaponized with the Internet. I know that you and many others in the TLS WG are saying what you are saying because you are trying to protect others who cannot protect themselves. I know. I respect that. I spent two of the happiest years of my life in sub-saharan Africa in the Peace Corps. I totally get the point of view of trying to help people and keep them safe. But, it is a very difficult issue. If I can use a different analogy, if the City of Monterey built a new sewer system and told me that to connect to it, I had to build a new house, I would scream! TLS is used in many, many places. The Internet is critical to the businesses of the world. You can't just say use something other than TLS. Or don't use the Internet. It's not so easy. I wish we could actually talk to each other quietly and reasonably. This is a very, very difficult problem. Nalini On Wed, Mar 14, 2018 at 4:16 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > On 14/03/18 23:00, nalini elkins wrote: > > The simple explanation is that people think they will have serious > > issues with TLS1.3 and actually, TLS1.2 when it is DH only. > > Of course some people who are used to MitMing connections will > have problems and will have to change. > > But that does not mean that their problems ought to be solved > by any change to TLS. > > IMO the costs to the broader Internet of breaking TLS like that > are far too high to optimse for these folks. It's understandable > that they'd prefer otherwise. > > People with such problems should IMO look elsewhere for > solutions and not be fixated on breaking TLS. > > Lastly, bear in mind that even if the people with whom you > are dealing have the best intentions, there really are people > who are paid large amounts of money to weaken Internet security > (see [1] for scant detail of just one country's efforts in > that regard) and that we have IETF consensus to oppose such > efforts, as far as it's in the IETF's remit to do so. > > So it doesn't really help the discussion to claim that > such-and-such a (set of person(s) is/are good actors - we do > assume that, but also that there are others who would like > the same changes to happen who do not share the IETF's goals > of making Internet security better as far as we can. > > S. > > [1] https://en.wikipedia.org/wiki/Bullrun_(decryption_program) > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
> > >- > Nalini, why don't you (the consortium) define the standard, then? > > > > > Indeed, if a “TLS13-visibility” standard has to be defined, it would > make sense for the consortium (rather than the TLS WG) to define it. > > > > I completely disagree. Here is why I would not prefer that route: > > > > 1. Multiple standards are likely to diverge. > > > Take the case of India, we have over 700 dialects. Many of them started > with the same root language. It has gotten so villages 10 miles apart > cannot talk to each other. We use English (a clearly non-native language!) > to communicate. > > > I could see the same happening with TLS and Consortium-TLS. Not a happy > thought for interoperability. > >Why is there any need for interoperability between TLS and Consortium-TLS? TLS is designed to be secure and reliable, and it's clear that Consortium-TLS finds such goals problematic. Yet I fail to see why that's a problem, since the claimed goal >is that Consortium-TLS would only be used within a single enterprise/datacenter, and thus would never need to interoperate with a world that valued security and privacy. Enterprises value security and privacy. They have a different job to do. What they are trying to do is to protect against leakage of data, do fraud monitoring, protect against malware and many other things. When this gets into the medical arena, it can even be lives. I don't even see how you can say what you are saying. Let me ask you then, what are the use cases you find to be valid? Saying that enterprises don't value security and privacy is really not terribly useful to resolving any discussion. Nalini On Wed, Mar 14, 2018 at 4:07 PM, Ryan Sleevi <ryan-ietf...@sleevi.com> wrote: > > > On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins <nalini.elk...@e-dco.com> > wrote: > >> >> All, >> >> In London now & back on email: >> >> >>- >> Nalini, why don't you (the consortium) define the standard, then? >> >> >> >> > Indeed, if a “TLS13-visibility” standard has to be defined, it would >> make sense for the consortium (rather than the TLS WG) to define it. >> >> >> >> I completely disagree. Here is why I would not prefer that route: >> >> >> >> 1. Multiple standards are likely to diverge. >> >> >> Take the case of India, we have over 700 dialects. Many of them started >> with the same root language. It has gotten so villages 10 miles apart >> cannot talk to each other. We use English (a clearly non-native language!) >> to communicate. >> >> >> I could see the same happening with TLS and Consortium-TLS. Not a happy >> thought for interoperability. >> > > Why is there any need for interoperability between TLS and Consortium-TLS? > TLS is designed to be secure and reliable, and it's clear that > Consortium-TLS finds such goals problematic. Yet I fail to see why that's a > problem, since the claimed goal is that Consortium-TLS would only be used > within a single enterprise/datacenter, and thus would never need to > interoperate with a world that valued security and privacy. > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
> > >>One strategy that's very effective for overcoming resistance to bad > ideas is to keep pushing the idea until nobody who's resisting it can > afford to continue doing so. > >There's a name for that tactics, it's called "consensus by exhaustion". (On the recent GNSO meeting this was briefly discussed as an issue within ICANN.) Guys, I know it is a lot of fun to talk about how others do not have the brains that God gave a termite and that maybe they are even the spawn of the devil. But, let's just use Occam's razor. Or as I tell my daughter, "if you hear hoof beats, it is likely not a zebra, it is a horse". The simple explanation is that people think they will have serious issues with TLS1.3 and actually, TLS1.2 when it is DH only. Nalini On Tue, Mar 13, 2018 at 4:45 PM, Artyom Gavrichenkov <xima...@gmail.com> wrote: > 13 Mar. 2018 г., 18:38 Ted Lemon <mel...@fugue.com>: > >> One strategy that's very effective for overcoming resistance to bad ideas >> is to keep pushing the idea until nobody who's resisting it can afford to >> continue doing so. >> > > There's a name for that tactics, it's called "consensus by exhaustion". > (On the recent GNSO meeting this was briefly discussed as an issue within > ICANN.) > >> > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
All, In London now & back on email: - >> Nalini, why don't you (the consortium) define the standard, then? > Indeed, if a “TLS13-visibility” standard has to be defined, it would make sense for the consortium (rather than the TLS WG) to define it. I completely disagree. Here is why I would not prefer that route: 1. Multiple standards are likely to diverge. Take the case of India, we have over 700 dialects. Many of them started with the same root language. It has gotten so villages 10 miles apart cannot talk to each other. We use English (a clearly non-native language!) to communicate. I could see the same happening with TLS and Consortium-TLS. Not a happy thought for interoperability. 2. The TLS WG of the IETF has many of the world's experts in defining such protocols. The years of collective expertise is remarkable. We want to work with the TLS group not try to recreate it. 3. The reason I support the enterprises and their voice in TLS is because I am naive enough to actually believe in the IETF. I believe that technical truth matters. That it is not actually the Vendor Engineering Task Force. That is a group of the vendors, by the vendors and for the vendors. I could see when this whole thing with taking away RSA was happening that correct though it may be, it was going to cause enormous disruption for many, many people in the commercial world. You may not believe it, but I am actually doing this because I really believe that we need one set of standards that everyone can use. I want it to be in the TLS WG. I want the TLS WG to be credible and succeed and I want the IETF to succeed. I believe that the Internet needs it. 4. Again, believe it or not, the TLS WG needs the enterprises. Of course, this is all my opinion only. These enterprises are a huge group of users of the IETF protocols and TLS in particular. The feedback of users is irreplaceable. Who are we building the protocols for if not the users? Sure, there are multiple sets, but these are a very large group. And, OK, maybe they don't state every need properly, let's try to help them. When I was designing products, I didn't expect the customer to come up with the design for the screen or the code. They don't have the skills to do that. They provide feedback and come up with requirements. I do the code design. Any organism which does not take feedback is not likely to thrive in the long term. Again, I am asking everyone to be open to working together. Nalini On Tue, Mar 13, 2018 at 11:27 AM, Andrei Popov <andrei.po...@microsoft.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? > > > > Indeed, if a “TLS13-visibility” standard has to be defined, it would make > sense for the consortium (rather than the TLS WG) to define it. > > > > Cheers, > > > > Andrei > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
All, The time has gotten away from me. I have to leave for the airport. I am taking my daughter to London & need to get us all packed & out of the house. I will write respond to all at length either from the airport or in London. Rich, so sorry about your health issues. My best wishes for a full and complete recovery. Nalini On Tue, Mar 13, 2018 at 10:39 AM, Salz, Rich <rs...@akamai.com> wrote: > >- I am happy to set up an informal session where all can meet and talk >quietly. Not everyone will be there on Sunday but maybe Monday breakfast >or during a break? Just let me know if you are interested & we can make >intros. > > > > I won’t be there (health issues), but I’ve already turned down such > private invites before. > > > > Standing up in front of a WG and talking about unpopular topics is hard. > As Richard said, kudo’s to USBank (and a BCBS org) for doing so. But if > you’re not willing to do the hard work, then you don’t get to have the IETF > address your concerns. > > > > I remember saying before that I firmly believe that the main, and > unstated, reason for wanting an IETF RFC on this is so that would-be > customers can point to vendors and ask for a common solution at a lower > price because the ability is now commoditized. With all due respect to the > people involved, I believe that is still the case. > > > > I have heard concerns that it is necessary to have a “speedy” solution. > Again, I strongly disagree with this. The standard organizations haven’t > even made TLS 1.0 illegal yet, as I said last time. What makes you think > that something is needed in under five years? I asked that question > before, too. > > > > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
Rich, A clarification: > Well, I’d be fine with a bunch of point solutions that were only sold and deployed in an enterprise because, as I said last time, this is too risky for the public Internet. What I meant about being fine with is a solution INSIDE the enterprise. But, we need a STANDARD because we need to have multiple vendors implement it. And, if there is a problem, then the vendors will point first to that non-standard solution as being the possible problem - which it certainly could be! We need to be able to solve problems for end users rapidly. Some of our members provide services to hundreds of thousands or millions of end users, so uptime is critical. Nalini On Tue, Mar 13, 2018 at 9:37 AM, nalini elkins <nalini.elk...@e-dco.com> wrote: > *>>* I hope that we can all work together to craft a solution. We don't > want fragmentation and multiple DIY solutions. > > > > > Well, I’d be fine with a bunch of point solutions that were only sold > and deployed in an enterprise because, as I said last time, this is too > risky for the public Internet. > > > We would be fine with that also. We are looking for something only INSIDE > the enterprise. > > > > > So then, who is “we”? > > > "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 > > > On Tue, Mar 13, 2018 at 9:32 AM, Salz, Rich <rs...@akamai.com> wrote: > >> *>* I hope that we can all work together to craft a solution. We don't >> want fragmentation and multiple DIY solutions. >> >> >> >> Well, I’d be fine with a bunch of point solutions that were only sold and >> deployed in an enterprise because, as I said last time, this is too risky >> for the public Internet. >> >> >> >> So then, who is “we”? ☺ >> >> >> > > > > -- > Thanks, > Nalini Elkins > President > Enterprise Data Center Operators > www.e-dco.com > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF101 Agenda Posted
*>>* I hope that we can all work together to craft a solution. We don't want fragmentation and multiple DIY solutions. > Well, I’d be fine with a bunch of point solutions that were only sold and deployed in an enterprise because, as I said last time, this is too risky for the public Internet. We would be fine with that also. We are looking for something only INSIDE the enterprise. > So then, who is “we”? "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 On Tue, Mar 13, 2018 at 9:32 AM, Salz, Rich <rs...@akamai.com> wrote: > *>* I hope that we can all work together to craft a solution. We don't > want fragmentation and multiple DIY solutions. > > > > Well, I’d be fine with a bunch of point solutions that were only sold and > deployed in an enterprise because, as I said last time, this is too risky > for the public Internet. > > > > So then, who is “we”? ☺ > > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
