Re: [TLS] datacenter TLS decryption as a three-party protocol

[Stephen Farrell <[e-mail]>]

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
>