With all respect to the authors for a well-written paper, this draft should not be adopted by TLS WG, because it would weaken the security of TLS as deployed in practice.
If the TLS WG were to adopt this draft, one of the likely outcomes would be implementation in a variety of popular TLS libraries, like OpenSSL and SChannel. Unfortunately, including interception capability in off-the-shelf software is like keeping your plutonium next to your potato chips; something is bound to go wrong. For instance, performance advocates may suggest turning on the interception capability in order to save cycles. If such advice is broadly adopted, we will effectively have reintroduced non-forward secret sessions to TLS. In TLS 1.3 there are no NULL cipher suites. Why should there be a commonly implemented mode that breaks forward secrecy? The "Weaknesses of Alternative Solutions" section nicely sums up the tradeoffs of various techniques. Under "Export of ephemeral keys," it says: > The complexity of the solution is a problem that adds risk. This is absolutely true, but doesn't mention the bearer. The enterprise that requires the interception bears the risk (or, more likely, the vendors who sell interception software). I think when balancing the monetary risk to the enterprise against the privacy risk to billions of consumer Internet users, the consumers should win. I would also point out that retrospectively decrypting pcaps asks TLS to do double duty: as at-rest encryption in addition to transit encryption. If, instead, each TLS server shares a copy of its plaintext via a TLS connection to an encrypted storage service, the enterprise gets much better security properties. Not only does it retain forward secrecy for in-datacenter traffic, it can control the keys for at-rest data much more tightly. Instead of every TLS frontend having the keys for retrospective decryption, those keys can be limited to auditors or security team members. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls