Expressly reacting to the viability of continuing to use TLS1.2 forever. As a network person, this sounds a little like suggesting that if we feel there are operational shortcomings in IPv6, then we should just plan to stay with IPv4, forever. And that approach may even be viable for the short term or in isolated situations. But for the longer term using TLS1.2 is likely to have the following issues for Enterprises:
* Industry groups will force us to use newer versions * Policy standards will evolve in similar fashions. * Likely there will be regulatory mandates in many of the marketplaces and business segments that large Enterprises participate in. * Software Products and Applications will attempt to remain current and will eventually sunset support for older protocol versions * Business Partners or Government agency customers may require TLS1.3. * Internal Security Teams may require TLS1.3, at some point in the future. And they should! And why should we NOT want and be able to utilize TLS 1.3 with it’s updated and enhanced capabilities. We DO WANT THIS! We just still need to run our networks and businesses and are badly wanting to work with the Working Group to assure our use cases can be accommodated, if at all possible. * And thinking further ahead, what would be the extended proposed strategy, when TLS 1.4 (or whatever comes next), is finalized. Adopting such a “Stay with the old product forever” would seem to be tantamount to hoping that TLS 1.3 (and 1.4, etc.), never get deployed. For VERY Security focused industries, such as healthcare and finance, this is directly opposite of what we want, need and support. We need security protocols to continue to evolve, improve and become as effective as possible, but they need to move forward with the understanding that operational perspectives are important as well. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich Sent: Friday, October 20, 2017 9:44 AM To: Darin Pettis <dpp.e...@gmail.com<mailto:dpp.e...@gmail.com>>; tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 * The question has been raised: "Why address visibility now?" The answer is that it is critical that the visibility capability is retained. It is available today through the RSA key exchange algorithm. We understand that the issue was raised late and have fallen on the preverbal sword for being late to the party but the issue is real. That is where the "rhrd" draft has come from. A way to retain that visibility capability but with a newer and more secure protocol. You achieve your needs right now by sharing the origin’s RSA key with your debugging agents. You can achieve the same needs in TLS 1.3 by keeping that architecture, although more information must be shared. This preserves the architecture and becomes “just” implementation. This has been brought up before. The first draft showed how to do this purely on the server side. Some members of the WG rose up and wanted explicit opt-in. The new draft does that. In retrospect, it turns out that opt-in is worse, mainly that there is no way to guarantee that this does not “escape” onto the public Internet. This makes sense, if you require opt-in from the client, then it is not surprising that, other entities besides the two parties engaged in the TLS protocol could, well, *require* clients to opt-in. As I and others have tried to show in email exchangers with Paul, this is a fundamental change to the nature of how TLS is used. Finally, as has also been mentioned, nobody is preventing you from keeping your servers at TLS 1.2 or earlier. TLS 1.2 was defined by RFC 5246 in 2008. A decade later, PCI-DSS is only ‘strongly encouraging’ TLS 1.2; the actual requirement is TLS 1.1! Why should we expect that TLS 1.3 will happen any faster? You have not made your case. 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
