Hi All There is a smart way to recover DH secret by a third party
It is DH tripartite base on EC paring https://tools.ietf.org/html/draft-urien-tls-dh-tripartite-00 Rgs Pascal 2016-09-25 23:20 GMT+02:00 Ackermann, Michael <mackerm...@bcbsm.com>: > I understand your concern over what the nation-state actors are doing but > it is not the same as what Enterprises do to manage their private servers, > networks and clients. > > Your final paragraph is quite a constructive question. "What > specifically would you have us do? What do you want in the protocol that > enables your needs, but doesn't make it possible for everyone in the world > to be surveilled? Please, make some specific suggestions." > > My personal perspective would be, that the approach to achieving an answer > to that important question, would start with: > > 1. Gathering protocol neutral requirements from all involved factions, > (with help and suggestions from people on the TLS list) > > 2. Brainstorming session(s) with people on the TLS list as well > potential users/operators, with objectives that include the design of a > solution that meets (hopefully) all known requirements. > > What I would like to see come out of the debate we seem to be currently > involved in, is the realization that significant operational/management > issues exist with TLS 1.3 and that the IETF is taking them seriously enough > to at least begin dialogue intended to address these issues, and > potentially work together to craft related solution(s). In my view this > issue is far too complex & pervasive to believe that any one person or > group's perspective would produce a viable overall solution. > > Again, let me restate, I don't think anyone is saying that we MUST have > RSA. But, we, as the clients of the IETF TLS protocol, would like to > work with you to assure we have workable, manageable and affordable > solutions, that meets our needs as well as the needs of others. > > -----Original Message----- > From: Salz, Rich [mailto:rs...@akamai.com] > Sent: Saturday, September 24, 2016 10:10 PM > To: Ackermann, Michael <mackerm...@bcbsm.com>; Pawel Jakub Dawidek < > p.dawi...@wheelsystems.com>; tls@ietf.org > Subject: RE: [TLS] Industry Concerns about TLS 1.3 > > > This lack of scope, depth and detail [in MITM infrastructures] are > > what drove us to install the packet collection infrastructures > > (debugging networks I think some are saying). > > At the risk of repeating myself and flogging this dead horse... What you > are doing is exactly what the nation-state actors are doing. I bet that > some even use that exact phrase of "packet collection infrastructure." > > I understand that if you want to use TLS 1.3, it is going to be expensive > and/or inconvenient; you're going to have to educate regulators and get > bespoke TLS endpoint solutions from vendors. Perhaps you can get the NSA's > to stop collecting everyone's Internet traffic for future decoding? > > Less flippantly, what specifically would you have us do? What do you want > in the protocol that enables your needs, but doesn't make it possible for > everyone in the world to be surveilled? Please, make some specific > suggestions. > > > > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
