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

TLS is a tool. Good guys want to use it to defend against the bad guys. Bad guys may want to use it against the good guys. (No surprise here, right?)

You cannot “sabotage” the second use case without sabotaging the first one at the same time. 

Two decades ago Jeff Schiller said something that remains perfectly valid today: (paraphrasing) “The price of having a secure infrastructure is our adversaries having a secure infrastructure”.

Understandably, you don’t want bad guys to use TLS “shield" against your “weapons”. Breaking this “shield” would accomplish this goal - but at a cost I (for one) don’t want to pay.
—
Regards,
Uri

> On Jul 14, 2017, at 02:02, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 14 July 2017 at 01:08, Kathleen Moriarty
> <kathleen.moriarty.ietf@gmail.com> wrote:
>> It sounds like for malware, we could do something to better document
>> your security options as well as monitoring.  While the documentation
>> is there for key pinning and trust anchors, this might not be obvious
>> to network managers - what RFC to look at and how they fit together.
> 
> Just an aside, though I think Kathleen already made this point:  If I
> were writing malware, I would use TLS.  It's pretty good at what it
> does and it's hard to distinguish from legitimate uses (there are some
> trick's suggested by McGrew's research on this point).
> 
> At the point that I have sufficient control over a host that I can run
> my software, then I would pin certificates and the best you could do
> is block me.  None of the advice about configuration of trust anchors
> (pinning, overrides, etc...) helps at that point.
> 
> Most discussions regarding breaking TLS focus on the breaking of TLS
> to *prevent* malware from infesting machines.  There at least the
> defender has a reason to attack end-to-end security.  But then we're
> talking about a very different deployment model than the gazillion
> emails recently have contemplated.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls