On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins <rdobb...@arbor.net> wrote:
> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote: > > Whether it justifies a loss of security is a separate question. >> > > It isn't a loss of security - it's actually a net gain for security. Security isn't a scalar quantity, so there's no way you can credibly assert this. OTOH, it's easy to point to the individual security properties lost by expanding the attack surface for a particular session key or by mandating key-reuse. Analyzing the impact of any particular mechanism for middlebox inspection is a question of tradeoffs: what are you giving up, what are you gaining, and is the trade worth it? The first two are questions of fact (though I'm under no illusion that there would even be broad agreement on those). The last is not: it's inherently subjective and among other things it depends on the threats, the alternative mechanisms available, and the value placed on the properties TLS provides to end users in its unadulterated form. Every one of your emails seems to boil down to an argument of the form "Organizations have infrastructure and operations set up to do inspection this way, so we need some way to apply that to TLS 1.3." I am unpersuaded by such arguments as a reason for standardizing a weakening of TLS. Given that, I would like to understand the origins of this approach to monitoring, as that may shed light on the hidden or unspecified constraints other than those imposed by TLS. (For example, if this approach is deemed to be less costly than doing endpoint monitoring, or if there are insufficient access controls for entry to the privileged network, or if the privileged network has systems that are too difficult to secure.) Kyle
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
