* 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
