Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

[Carl Mehner <[e-mail]>]

On Mon, Jul 17, 2017 at 9:11 AM, Dobbins, Roland <[e-mail]> wrote:
>
>
> On Jul 17, 2017, at 15:59, Carl Mehner <[e-mail]> wrote:
>
> the only way that this draft would help you
> with malware analyzing)
>
>
> This statement is factually incorrect.  It’s not the only way, as I've just
> explained.

Ok, sure, sorry for being imprecise. it's the only way that would help
you if you were trying to use this draft. If you're not using this
draft, then why are we talking about malware here? Do you have an
example of where malware would be on your intranet where using this
draft would help you?

> Again, why are you trying to pretend that the use of this technique is not
> prevalent nor important in the security context, when it is in fact quite
> prevalent & important, & has been for many years?

First, I was not the person you asked this to the first time, unless
you were asking the list, if you were I think there has been a
considerable effort to try and understand. Second, now that you have
asked me... I have, that's why i'm asking questions, (that you haven't
answered) Thirdly, just because something is prevalent and important
and has been used for many years, doesn't mean that it should
continue.

Looking at HTTP-only traffic for debugging was prevalent and sometimes
was even considered "OK" because, "we're in an intranet, not going
over the Internet", now we understand that it is not longer acceptable
to use plaintext traffic. Because of that tools changed, network
designs changed. A similar thing is happening now. Non-FS was ok,
because it's "intranet", now, it is not tools and designs will have to
change. (And since we are throwing around PCI hypotheticals.. maybe
PCI will mandate forward secrecy without static keys because it's more
secure.. we just don't know.)
The bar, as Steven pointed out earlier, is for you to prove. You
should be proving that it is necessary, not just that it is prevalent
or easier.

> And why are you unable to understand that that in the case of an additional
> layer of attacker-generated crypto nestled within a TLS tunnel, as you
> posited, that the ability to simply detect the presence of such an
> additional layer of unexpected crypto, even without the ability to
> immediately decrypt it, has substantial value in a security context?

I didn't say that I didn't understand that knowing nested crypto was
occurring was beneficial. I do. I agree it is beneficial. I'm trying
to get you to explain how this draft helps with that.

> Are you unfamiliar with the concept of traffic analysis, in the crypto sense
> of the term?
I recently analyzed some malware that was sending encrypted traffic
back and forth nested inside TLS. But we didn't need to open up the
TLS stream to know that it was malware. Also, this draft did not apply
to that strain of malware, it wouldn't have even helped determine that
the crypto was doubled.