On 22/10/17 21:48, Steve Fenter wrote: > The main problem with not addressing the TLS visibility issue now is > that no one knows when a vulnerability will be discovered in TLS 1.2 > that forces enterprises to upgrade to TLS 1.3. We've had guarantees > that TLS 1.2 and the RSA key exchange are going to be fine for 5 to > 10 years, but nobody knows that, particularly in today's security > environment. I've also learned that getting a solution in place > through the IETF is a multi-year process, and then vendor adoption > time has to be added on top of that. Enterprises don't want to be > caught in a position where a vulnerability is forcing us to upgrade, > and we are starting at ground zero on a multi-year process to restore > TLS visibility. We have to get out in front of this problem so we're > not caught unprepared.
Wait. What? One of your arguments for needing snooping is that you claim a lack of competence in debugging applications that use TLS. So to solve that, you propose we introduce a rarely used, sporadically supported method of leaking keys to third parties. IOW, you add what's called a vulnerability and do so in a complex manner in code paths that'll hardly ever be used (according to the proponents, they'll only be used in the "proper" places, or at least, none of you have so far ever acknowledged the falsity of that "proper" places magical thinking). Rarely used complex code for leaking keys... hmm, now what is that likely to lead to? Oh yes, bugs. But now you claim that a well tested protocol with fairly mature implementations (TLS1.2) might have bugs that cause you to need to add your additional complex key-leaking vulnerability feature which'll magically have no bugs? I think you can fairly claim a worst argument of the year prize for that one;-) S. PS: Your claim about "guarantees" is just false afaics. I saw no such thing on the list. Please desist from inventing statements that were not made, or point me at where someone said something that is even remotely possible to confuse with such a guarantee. (Combining risible argument and false claims really isn't wise.) > > Sent from my iPad > >> On Oct 20, 2017, at 11:57 AM, "Salz, Rich" <rs...@akamai.com> >> wrote: >> >> >> >> So it sounds like we are in agreement that continuing to use TLS >> 1.2 is not a viable long term alternative. >> >> >> Long-term is a subjective term, and using it can lead to >> misunderstandings. >> >> Based on current and previous actions around SSL and TLS versions, >> you can use TLS 1.2 for at least five, likely at least 10, years. >> >> >> >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls