nalini.elk...@insidethestack.com writes: > [ Unknown encryption status ] > [ Unknown signature status ] > > > >>> >>> What I am saying, in relation to your "Delivering a stable product" >>> comment is that over time various industries have learned what it takes to >>> "Deliver a stable product". We did not >>want to invest millions in >>> these debugging networks. But we learned the hard way, that it was >>> necessary. >>> I am not a member of the banking coalition that started this subject, nor >>> of the banking industry at all, but I certainly understand their >>> perspective and am concerned about the same >>unmanageable future they >>> described. > >>Do Akami, Cloudlflare and Google magically not have these problems? > It would be very interesting to get the network diagnostic and > operations people (rather than the architects) of the above companies > involved in this conversation.
Hi, technical person most directly responsible for incident response and urgent debugging here. We modify endpoints to get what we need. We did have taps that relied on knowing the RSA Kx secret... but haven't used them in about a decade. I think the banks have an answer not available to the global passive adversaries: modify the server or client to use a fixed ECDH share, then use tech much like their current choices. It'll take a while to develop, but nobody in that environment plans to move to TLS 1.3 for operational systems any time soon anyway. -Brian > Also, you know, companies don't really enjoy spending money on network > diagnostic products which might be considered overhead. So, if they are, we > might do them the courtesy of not thinking that they are foolish to do so. > Why don't we listen to each other? I know at IETF, I often hear that we > don't get enough operators to comment and give feedback. Well, here you have > some. It may be that these companies have problems that are different from > Google's (just as an example). > Isn't our goal to have the best standards possible? Any organism (including > the IETF), needs feedback to thrive. > Nalini >> >> Thanks >> >> Mike >> >> >> >> -----Original Message----- >> From: Jeffrey Walton [mailto:noloa...@gmail.com] >> Sent: Friday, September 23, 2016 10:55 AM >> To: Ackermann, Michael <mackerm...@bcbsm.com> >> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org >> Subject: Re: [TLS] Industry Concerns about TLS 1.3 >> >> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> >> wrote: >>> From the perspective an Enterprise that runs these applications and has >>> invested HEAVILY in the debugging networks......... >>> >>> The reason we are debugging these networks is so that "The 5-6 order of >>> magnitude of folks using them" will have good service. If they do not, >>> they will consider competitors and/or generate a litany service calls or >>> complaints. I.E. When these "Folks" are slow or not working they >>> are just as unhappy as we are. >>> >> >> Isn't that the market operating as expected? Those who deliver a stable >> product at a competitive price are rewarded, while those who fail to deliver >> or deliver at an unreasonable cost are not? (Some hand waiving). >> >> If all providers failed to deliver or delivered an inferior product, then it >> might indicate a major course correction is needed. But I don't think that's >> the case here. >> >> Jeff >> >> >> 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 > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > 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 > > > >>> >>> What I am saying, in relation to your "Delivering a stable product" >>> comment is that over time various industries have learned what it takes to >>> "Deliver a stable product". We did not >>want to invest millions in >>> these debugging networks. But we learned the hard way, that it was >>> necessary. >>> I am not a member of the banking coalition that started this subject, nor >>> of the banking industry at all, but I certainly understand their >>> perspective and am concerned about the same >>unmanageable future they >>> described. > >>Do Akami, Cloudlflare and Google magically not have these problems? > It would be very interesting to get the network diagnostic and operations > people (rather than the architects) of the above companies involved in this > conversation. > Also, you know, companies don't really enjoy spending money on network > diagnostic products which might be considered overhead. So, if they are, we > might do them the courtesy of not thinking that they are foolish to do so. > Why don't we listen to each other? I know at IETF, I often hear that we > don't get enough operators to comment and give feedback. Well, here you have > some. It may be that these companies have problems that are different from > Google's (just as an example). > Isn't our goal to have the best standards possible? Any organism (including > the IETF), needs feedback to thrive. > Nalini >> >> Thanks >> >> Mike >> >> >> >> -----Original Message----- >> From: Jeffrey Walton [mailto:noloa...@gmail.com] >> Sent: Friday, September 23, 2016 10:55 AM >> To: Ackermann, Michael <mackerm...@bcbsm.com> >> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org >> Subject: Re: [TLS] Industry Concerns about TLS 1.3 >> >> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> >> wrote: >>> From the perspective an Enterprise that runs these applications and has >>> invested HEAVILY in the debugging networks......... >>> >>> The reason we are debugging these networks is so that "The 5-6 order of >>> magnitude of folks using them" will have good service. If they do not, >>> they will consider competitors and/or generate a litany service calls or >>> complaints. I.E. When these "Folks" are slow or not working they >>> are just as unhappy as we are. >>> >> >> Isn't that the market operating as expected? Those who deliver a stable >> product at a competitive price are rewarded, while those who fail to deliver >> or deliver at an unreasonable cost are not? (Some hand waiving). >> >> If all providers failed to deliver or delivered an inferior product, then it >> might indicate a major course correction is needed. But I don't think that's >> the case here. >> >> Jeff >> >> >> 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 -- Brian Sniffen Akamai Technologies _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
