I might want to try responding to the right thread. Apologies for the noise. ;-)
Kyle On Sat, Jul 15, 2017 at 9:08 AM, Kyle Rose <kr...@krose.org> wrote: > I've rebased from the kernel master HEAD (4.12.0+), tested, and > force-pushed the repository. > > Conveniently, it looks like, since the last time I searched for one, > someone added an ECDH implementation to the kernel. That makes this a lot > easier. > > Kyle > > On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose <kr...@krose.org> wrote: > >> 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
