On Mon, Jul 17, 2017 at 9:11 AM, Dobbins, Roland <rdobb...@arbor.net> wrote: > > > On Jul 17, 2017, at 15:59, Carl Mehner <c...@cem.me> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
