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" <rdobb...@arbor.net> 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 <rdobb...@arbor.net> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
