Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Colm MacCárthaigh <[e-mail]>]

On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell <[e-mail]
> wrote:
>
> (*) I am not asking that people tell me that "pcap+key-leaking"
> might work, but for them to describe when that works but nothing
> else works. And that has to include the details of what it is
> they can only find in the recovered cleartext that cannot be
> detected without access to cleartext using this particular
> method.
>

Of course other techniques could work, every system involved from the
network devices to the endpoints is practically Turing complete. For me,
the more interesting question is really whether the providers/users are
likely to take on the costs of doing it differently, or wether they are
more likely to block TLS1.3 and stay on legacy crypto. Given everything
I've read, I think the latter is more likely.

> Are you skeptical that existing network operators don't do this kind
> > of decryption?
>
> I believe that people do this kind of key-leak+pcap decryption.
>
> People do all sorts of other unwise things too (myself included,
> and fairly frequently;-), that is not a reason to encourage more
> of "it" for any "it."
>

Well, they have the keys, and they have the desire, so I expect them to do
it by some means. The question then becomes not about promoting or
encouraging it, but how we may limit the damage and achieve the best
outcome. I don't understand how proxies are a better solution, as I've
outlined; they have drastically worse security properties.

I would also note that the "use a proxy" argument seems to me
> to mostly be offered as a strawman counter-argument by folks
> who would like to break TLS via static DH, and doesn't seem to
> be a common argument offered by those against breaking TLS.
> (Adding proxies is of course another way to break TLS, depending
> on how and where it's done.)
>

I can't make sense of this paragraph. A static-DH solution has no need for
proxies, so I'm unclear on why a static-DH proponent would suggest using
them. If proxies aren't the alternative, then what is? are you suggesting
none? That's the brinksmanship approach, which is valid of course, you can
risk TLS1.3 adoption. And the pcap operators may flinch first, or you may.
But is it really wise to ask your opponent for the evidence that they won't
flinch first?


> > I'm not skeptical of that at all, but would be interested in what
> > acceptable evidence would look like.
>
> I'm not sure of the phrase "acceptable evidence" but regardless
> of that:
>
> TLS is an important protocol, extremely widely used. For any attempt
> to weaken or break TLS, I think the onus is on the proponents of the
> break-TLS proposal to produce convincing evidence that their scheme
> will at least be a net positive, considering the entire ecosystem
> that is dependent on TLS. And even if there is evidence that a scheme
> would be a net positive, it may still be a bad idea, if the negative
> aspects of the scheme have serious enough impacts in some use-cases
> for TLS.
>
> That's a pretty high bar, yes. And so it should be. I'm not at all
> clear it can be cleared, ever.
>

Real world: They have the keys, so they can break FS by using proxies if
they want. If they do that, and they likely would, everyone is much /worse/
off because now there's less FS, more plaintext floating around, and more
exploitable software floating around. Is that really a sensible outcome?


>
> > Though I'll point out again: TLS 1.3 is the new thing that we want
> > to gain adoption, so really we should be looking for evidence that
> > it's /not/ a burdensome change.
>
> Sure, that is another fine thing to do. It'd be helped along if we
> had evidence about the precise scenarios in which the pcap+key-leak
> wiretapping is the only possible usable approach. That hasn't been
> described on the list. (It has been asserted that such scenarios
> exist, and it has been claimed that we should all know and accept
> all this already, but those were TBBA non-arguments.)
>

Imagine you're blindfolded, with your finger on a button that fires a gun.
The gun might be pointed at you, it might be pointed at your opponent. Your
opponent has no blindfold. Your argument is "Tell me if the gun is pointed
at me or I'm going to push the button". Now if the gun is pointed at them,
can you really trust them? And if it's pointed at you, why should they care
to help you out?

-- 
Colm