Hello Phil, > I have a use-case for allowing an MITM to monitor traffic, but not > impersonate a server, and to allow MITM signing for replay of > server-responses to support caching. > This sounds like attack monitoring (going beyond DoS for which SNI frequencies might already be helpful). This used to be possible by passing certificate private keys, until we all embraced (EC)DHE. This is still an option for you of course, since you're violating the idea of (EC)DHE anyway, at least between the monitor and its related TLS peer.
> As far as I'm aware, TLS currently only supports a shared-secret once > session initialisation is complete, so I'd need to extend the protocol to > support asymmetric encryption for the session. > I wonder if you'd need to extend the *protocol* or rather its *implementation* to share private/secret key material. You could probably create a side-channel over which you communicate this efficienctly, based on the random pieces in Hello, for instance. Any such implementation would sound the alarm bells for this option (and probably not make it a default option) that the TLS protocol can't ring because it is just a protocol. My suggestion would be to let the monitor supply the private/secret key material its related TLS peer, so it has more control; also, for TLS implementations the import of key material is perhaps less scary than the export (or more possible, if PKCS #11 is used). Your monitor might decide to let go of monitoring traffic, to monitor other traffic and perhaps to share key material between certain sessions when under attack. Be careful with all of this though! > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? > Clearly, the WG does not like this idea. Same with me. But if you tried something implementation-specific, or perhaps even standardise an explicit side-channel protocol, you may be more likely to get the work done because that would constitute an explicit and independent choice on the part of the administrators. TLS is so full of options that the eyes of admins already glaze over -- what you are proposing is explicit weakening of TLS, and it could slip into a configuration too easily as part of the confusion that the complexity of the protocol already causes. It could be interesting to let the WG know what your course of action will be, so we can positively reference any such requests in the future. Cheers, -Rick _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
