Judson Wilson wrote: > > I think this challenge is best solved by putting the information on the > wire in some way, possibly as a special industry-specific extension (used > only by those who are bent on shooting themselves in the foot). The benefit > being that if the TLS channel is alive, the session information is > available to the monitor. Just as a strawman, the client could transmit > session info in special records, encrypted by a public key, and the > monitoring equipment could scoop these up. For compatibility with servers > outside the network, a middlebox could somehow filter out these records. > > It sounds like the need is large enough that such an effort is feasible, > and it would be good to keep normal TLS 1.3 unambiguously forward secure. > (There IS still the question of how to make sure that the extension is not > enabled in endpoints it shouldn't be.)
Whoa there. What you're describing is essentially the Clipper-Chip & Skipjack encryption https://en.wikipedia.org/wiki/Skipjack_(cipher) I'm sorry, but the IETF decided back then that it doesn't want to standardize such technology: https://tools.ietf.org/html/rfc1984 I'm sorry, but I'm still violently opposed to the IETF endorsing backdooring of security protocols. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
