The problem is that the actual solution to this problem is to accept that you aren't going to be able to decrypt the streams, and then figure out what to do instead. Which is work the proponents of not doing that are not interested in doing, understandably, and which is also not the work of this working group.
I'm skeptical that there is a way for this working group to solve the proposed problem, but if there is, it involves figuring out a way to do this that doesn't make it easy to MiTM *my* connections, or, say, those of activists in dangerous places. On Wed, Jul 19, 2017 at 7:33 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > 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 > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
