On 17 Jul 2017, at 16:52, Carl Mehner wrote:
Do you have an example of where malware would be on your intranet
where using this
draft would help you?
Sure - detecting attempted additional compromise and lateral movement
utilizing exploits within TLS-encrypted traffic.
Another is detecting (and subsequent blocking of) the download of
malware by intranet users.
Detecting data exfiltration is also a common use of this technique in
intranet environments.
Thirdly, just because something is prevalent and important
and has been used for many years, doesn't mean that it should
continue.
Sure - but it's also important to understand the mechanisms and
techniques which are important to network operators, and to provide
non-burdensome, non-iatrogenic ways for them to continue fulfilling
critical functions within their own intranet environments.
Non-FS was ok, because it's "intranet", now, it is not tools and
designs will have to
change.
I understand what you're saying; but, conversely, isn't it in the
interests of all of us working within this WG to help define practicable
solutions that network operators can use on their own intranets to
troubleshoot and ensure the security of those networks without requiring
iatrogenic measures?
(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.)
Agree with you 100%. That being said, the PCI/DSS board are quite
well-versed in the monitoring techniques utilized by relevant
organizations, so (hopefully!) they'll take this into account, when the
time comes.
But you're absolutely right - 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.
The problem is that in many cases, the changes required to accommodate
pervasive PFS within the intranet have the potential to be both
impractical as well as iatrogenic in nature. I completely agree with
you that PFS is very important whenever sending/receiving traffic across
multiple spans of administrative control, like the public Internet.
I'm trying to get you to explain how this draft helps with that.
It helps because if the intranet network operator has visibility within
the TLS tunnel on his own intranet, he has the opportunity to infer the
existence of unknown and unexpected traffic types, including possible
superencryption.
Just being able to something that looks out of place and warrants
further investigation, without being able to instantly classify it, is
very valuable, in a security context.
Does that make more sense?
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.
Understood - you were able to user some other mechanism, like traffic
analysis or an endpoint mechanism, to determine the the presence of this
particular malware, yes?
Unfortunately, this isn't always going to be the case, in many
circumstances and contexts.
it wouldn't have even helped determine that the crypto was doubled.
Was the malware in question using countersurveillance/obfuscation
techniques that made it more difficult to infer the presence of the
additional layer of encryption?
-----------------------------------
Roland Dobbins <rdobb...@arbor.net>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
