> I agree. > > My point is that if this draft were accepted, then the > infrastructure for the above scenario would all be in > place (the DH value for the snooper and the code to expose > session information to that snooper) and the above > scenario would be more likely to happen, more often. > IOW, by standardising draft-rehired, we'd *also* be > putting in place standard building blocks for an OOB, > client is never told mechanism.
I don't see it that way... For me, using the capabilities provided by this draft in order to get an OOB-only "no client involved" mechanism is more difficult and probably less efficient than creating one from scratch... That being said... One thing that bothers me from my last emails is that I seem to find myself on the draft-defending side of the discussion while I don't really like the draft itself due to the concerns I pointed out in my first email... I'm not fully against adding monitoring capabilities to the protocol, but I would prefer a "no-monitoring-allowed" TLS if the alternative was going with an insecure tapping mechanism. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
