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

[Ted Lemon <[e-mail]>]

It seems to me that all the use cases you just described require the
*client* to have a static key, since the client is the thing that the
operator controls. If the client uses an unknown key, is malware or
unauthorized.

On Jul 14, 2017 20:42, "Roland Dobbins" <[e-mail]> wrote:

> On 15 Jul 2017, at 1:01, Melinda Shore wrote:
>
> It might make sense to kick it over to ops for a discussion with people
>> whose meat and potatoes is monitoring, management, and
>> measurement.
>>
>
> As someone who is ops-focused, I think this is an excellent suggestion!
>
> There have been several assertions posted to the list recently regarding
> various aspects of security and their intersection with encryption.  It may
> be useful to take a moment and clarify a few of them.
>
> With regards to DDoS mitigation as it relates to encrypted attack traffic,
> only a subset of attacks in a subset of situations can actually be
> adequately mitigated without full visibility into (and often the ability to
> interact with) the traffic within the cryptostream.  There are various ways
> to approach this issue, including full session termination and
> 'transparent' detection/classification, the latter of which isn't of course
> feasible in a PFS scenario.  Each of these general approaches has its
> advantages and drawbacks.
>
> Very specifically, fingerprints of encrypted streams are not in fact
> adequate for DDoS defense; again, they're only useful for a subset of
> attack types in a subset of situations.
>
> In the case of detecting and classifying hostile activity within a given
> network - which isn't limited to malware spreading, but includes data
> extraction, attempts at unauthorized access, attempts at subverting
> additional devices, et. al. - the same basic caveats apply.  It is not in
> fact possible to adequately detect and classify all, or even a large
> subset, of hostile network traffic without visibility into the
> cryptostream.  There are some gross behaviors which can be
> detected/classified whilst standing outside the tunnel, but assertions to
> the effect that all or most of what's required in this arena is possible
> without visibility (one way or another) into the relevant encrypted traffic
> are incorrect.
>
> It's also important to understand that inserting proxies into multiple
> points of a network topology is not cost-free, nor an unalloyed good.  It
> is impractical in many circumstances, and has highly unwelcome side-effects
> in many more, including a negative impact on reliability, performance, and
> availability, as well as broadening the potential attack surface.  Endpoint
> monitoring does not scale well, is often impossible to implement due to
> both technical and administrative challenges - and one can't really trust
> endpoints to self-report, anyways, as they can be subverted.
>
> In many scenarios, one form or another of network-based visibility into
> encrypted traffic streams within the span of administrative control of a
> single organization is legitimate, vital and necessary.  It is not
> 'wiretapping', any more than tools such as tcpdump or telemetry formats
> such as IPFIX and PSAMP can be categorized as 'wiretapping'.  The fact is,
> the availability, confidentiality, and integrity of systems, applications,
> and networks that everyone on this list relies upon is highly dependent
> upon the ability of organizations to have visibility into encrypted traffic
> streams within their own networks, for purposes of security as well as
> testing and troubleshooting.
>
> How this can be accomplished is a matter for further discussion.  But it's
> important that everyone focused on this topic understands that it is simply
> not possible to successfully defend against many forms of DDoS attacks nor
> to detect and classify hostile network traffic in the context of encrypted
> communications without visibility into the traffic in question, via some
> mechanism.  The same goes for troubleshooting complex problems.
>
> Those with operational experience at scale will likely recognize and
> acknowledge the difficulties and challenges noted above; others may wish to
> consider these factors and their impact on the operational community and
> the networks, services, and applications for which they are responsible,
> and upon which we all depend, every day.
>
> -----------------------------------
> Roland Dobbins <[e-mail]>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>