Sent from my iPhone
> On Jul 14, 2017, at 8:02 AM, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 14 July 2017 at 01:08, Kathleen Moriarty > <kathleen.moriarty.i...@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. I do think we could help tie together this advice for the many operators using TLS so they know and understand options better. Yes, agreed, detection at that point relies on anomalous behavior on the managed end point, connection information (unusual destination, size of packets, timing of streams, etc.), or known indicators of compromise. These all work with encryption and TLS should not be a hinderance to incident detection 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. I think the points on why the solution doesn't help with malware have been clear, but just in case, preventing malware from infecting endpoints receiving content over HTTP/TLS can also be done using indicators of compromise. Breaking TLS only works if the malware has been identified and can be detected by the analysis box. This does work when it's been deployed to newly infected servers when the malware hasn't been altered enough to avoid detection. This is useful to enterprises, but you'd need the server key or more realistically going forward, would need a TLS proxy. Otherwise, with the proposed solution, your still relying on indicators of compromise that can be detected using the encrypted traffic. Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
