Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Hi Steve,

Thanks for taking the time to detail out your concerns and current use
cases.  This is helpful.

On Tue, Jul 11, 2017 at 9:39 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 12 July 2017 at 09:59, Steve Fenter <steven.fenter58@gmail.com> wrote:
>>> And if you had one an estimate for how much malware does it's own
>>> obfuscation or home-grown crypto in addition or instead of using TLS.
>>> The reason to ask is that as soon as malware does that then you
>>> are back to analysis based on ciphertext only. From descriptions
>>> of advanced attack schemes, they do seem to do both when calling
>>> home or exfiltrating data. In which case I think your argument
>>> falls.
>>
>> I don't have any numbers for home-grown crypto.  I would think the odds are better for the enterprise if they can decrypt and inspect whatever portion is TLS.
>
> Wouldn't malware avoid connecting to servers that offer the wrong
> credentials?  Implementing elementary key pinning or overriding trust
> anchors is pretty trivial - it's a feature that enterprises frequently
> rely on after all.

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.

The points Stephen, Ted, Martin have made are good.  A TLS overview
document with an appendix of use cases might be a good start to help
fill this gap for operators.  Even if it isn't published, we could
figure out wiki space or something like wikipedia to make sure it's
available to operators. If the start of this documentation looks like
it will generate new work developing alternate ways to accomplish the
goals while maintaining the integrity of TLS, a new WG could even be
an option.

For malware, the proposed solution (Matt Green draft) isn't a great
fit as the server side won't be managed within your enterprise to
allow for the decryption described in the proposal.

For the other parts of your original message that were snipped from
this thread, I have a few questions/comments to see how we might be
able to narrow the scope and clarify a few things.

For the Troubleshooting description, could redefining the end point of
the server work as terminating at a load balancer to help with at
least some of your use cases?

For the threat detection and security analytics, I know a number of
current products rely on the ability to TLS.  The primary concern here
would be the remote server not managed by the enterprise.  TLS 1.3
prevents this from being possible and the proposed draft doesn't help,
so I think it would be best to figure out a way forward for this use
case either with the help of MILE (incident responders) or others.
Currently products use proprietary methods to accomplish this task (at
least some do).  For DDoS, the experts say they can work with
fingerprints of encrypted streams, so it's other attack types that may
require some thinking through of options.  I'm happy to chat about
that as I've done a lot of work in incident response and know of
others that may be able to assist as well.

I'm still reading through messages and drafts on this topic, so this
message should not be read as a position on either side, but more to
narrow the scope if possible and think through what is being requested
and why - so it is clarified.

Thanks.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 

Best regards,
Kathleen