Andrew, What would probably be most helpful here would be if you tried to describe what you think your requirements are in some sort of protocol-neutral fashion.
-Ekr On Fri, Sep 23, 2016 at 1:31 PM, BITS Security < bitssecur...@fsroundtable.org> wrote: > Rich (et al.) -- I understand where you are coming from but I will poke a > little bit at this portrayal. > > We are not here hat-in-hand asking for a return to RSA key exchange to the > proposed standard. We do however want to raise our concern (and hopefully > your awareness) of what appears to be an unintended consequence of the move > to PFS-only choices. > > What is happening from our perspective is choice is being removed and an > adequate replacement has (seemingly) not been identified. This lack of > choice may not affect everyone and every use-case but it will predictably > affect large, complex, highly regulated enterprises in a serious manner. > This is a classic case of security requirement being in conflict with a > different security requirement. > > IETF protocols are run extensively both on the public Internet and within > private enterprises. Any decisions made by the TLS Working Group will > affect both environments, and the needs and requirements of both > environments should be considered. > > -Andrew > > > -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich > Sent: Friday, September 23, 2016 3:08 PM > To: nalini.elk...@insidethestack.com > Cc: tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > > > 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. > > Nothing has ever stopped them. Never. Participation is as simple as > joining a mailing list. The IETF has been doing SSL and TLS for nearly 20 > years. It is not a secret. It was incumbent on them to reach out and get > involved. > > > 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). > > Don't try to equate "listen to each other" with "meet my requirement." > The message has been stated, very clearly, from individuals, WG members, > through document editors and WG chairs and up to Security Directors: > static RSA is not coming back to TLS 1.3 . Since before the last IETF this > was the message, consistently. So perhaps you should answer the question > first -- why aren't *you* listening? :) > > PFS is also possible in TLS 1.1 and later. What does, say USBank, do to > prevent PFS in their existing deployment? Why won't additional controls to > prevent TLS 1.3 and its mandatory PFS be expected to work here as well? So > far all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to > move to TLS 1.3" Shrug. There are bugs everywhere. Maybe there's bugs > in TLS 1.3 too. > > Look, pretty much the entire world is being spied on by national-scale > adversaries who are recording all traffic for eventual decryption and > correlation. *Almost everyone* is having their traffic surveilled. The > problems of debugging a set of enterprise apps doesn’t amount to a hill of > beans in that world. It just doesn't. Same for a particular industry's > regulatory requirements. > > > Isn't our goal to have the best standards possible? Any organism > (including the IETF), needs feedback to thrive. > > Oxygen, coke, and cookies too. > > -- > Senior Architect, Akamai Technologies > IM: richs...@jabber.at Twitter: RichSalz ______________________________ > _________________ > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
