On 19/07/17 17:58, Benjamin Kaduk wrote: > On 07/19/2017 11:49 AM, Stephen Farrell wrote: >> >> On 19/07/17 14:09, Benjamin Kaduk wrote: >>> As Stephen noted in his presentation, a lot of the proposals for passive >>> decryption can be seen as trying to turn TLS from a two-party protocol >>> into a three-party protocol. Which is probably the right way to think >>> about it, even when all (three) parties are within the same >>> administrative domain. >>> >>> Stephen also said something about it being hard to shoehorn a >>> three-party protocol into the API for a two party protocol. But >>> depending on the specifics, maybe it's not so bad. For example, if the >>> only semantics you need are a new API for "this is the list of third >>> parties I authorize to wiretap this connection", the scope seems fairly >>> limited. >> I would question the size of the set of applications for which the >> semantics of such a list/interface could make sense. For example, >> asking a person if they're ok with some random IPv6 address spying >> on a TLS session makes zero sense for example. >> > > Sure, some random IPv6 address makes no sense, and is not > cryptographically bound to anything. > On the other hand, "this (semi-)static DH key is one currently used by > my enterprise's network monitoring system, and is allowed to read my > traffic" seems closer to what is being asked for.
I don't know how that kind of identifier can be made meaningful for almost any application where the identifier is not already meaningful, and in many such cases I would guess there are already hop-by-hop behaviours where TLS is not e2e for the application layer (MTAs etc.) But sure, someone could do the work to describe some applications that might have a need for a multiparty security protocol like that I guess. As I said, my guess is that the size of that set of applications is small. > > As has been said downthread, the recommendation is not "you should > always use this thing", it's "you should do TLS 1.3 without backdoors, > but if you really need to, this is a way to do so with known and limited > properties". I can see why people might consider that some kind of compromise that's less bad, but I think searching for "less bad" is not at all the right approach. I don't mean that we oughtn't investigate possible scenarios, but searching for a compromise is not in itself a good goal here. Cheers, S. > > -Ben > > -Ben >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
