To be honest, I’m rather surprised that this group continues to spend time on this. I’m of the opinion that the chairs should step in and put this discussion on hold until the work on TLS 1.3 is complete. This, and any document of the same goal, are eating up time and energy that should be directed to completing the work this group was chartered to do. There’s no indication that there will be any consensus on moving forward with any such document in this group, and I don’t think that will change any time soon.
Those advocating for some standardized method of subverting the security properties of TLS have been offered numerous options in good faith, and continue to reject them all. I’m aware of extremely large enterprises that in fact require TLS 1.2 with PFS, as they made the investment in addressing this issue early on, and do so effectively. This can be solved without changes to the protocol or a standardized “backdoor” - and is being done today by at least some enterprises. I understand that this complicates the work that some do, and will mean additional engineering or spending to deal with it, when they eventually move to TLS 1.3; that said, I don’t think their decision to take the easy route in traffic inspection and ignore the evolution of 1.3 till the last moment should lead to adding new risk to every other TLS user, especially those that invested in long term solutions that deal with these changes. I’m of the opinion that this discussion is no longer productive; there’s no indication that there will be consensus on this or similar documents, good faith efforts have been made to offer alternatives - in multiple discussions, it’s distracting from the work of completing 1.3. To me, the most logical thing to do is move on, finish the work on 1.3, and then reevaluate (not that I expect consensus to emerge then either). -- --*Adam Caudill* http://adamcaudill.com
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
