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
