On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael <[email protected]> wrote: > 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.
It totally is. You record the traces, then use the private key to decrypt them. The packets are stupid, they don't know the difference! > > 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) You know, you could have made those requirements known to us in this email. How many months extra do you want us to take? > > 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. Let me point out that there was a rechartering debate in 2013 which included lots of discussion about requirements, and about 16 drafts in between then and now. What you want is to go back to the drawing board because you weren't aware of what the IETF was discussing instead of describing your requirements and what would meet them. Huge amounts of protocol analysis will need to be redone as a result: might be good for some people, but we're already far behind schedule and with lots of unresolved issues. > > 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. You can use static ephemeral shares on the server side if you want. Is that good enough? You can do what Brian Sniffen described above, and you have 1.5 decades to shift or so. > > -----Original Message----- > From: Salz, Rich [mailto:[email protected]] > Sent: Saturday, September 24, 2016 10:10 PM > To: Ackermann, Michael <[email protected]>; Pawel Jakub Dawidek > <[email protected]>; [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
