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

Steve Fenter <steven.fenter58@gmail.com> Tue, 11 July 2017 18:39 UTC

Return-Path: <steven.fenter58@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA513179A for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 11:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGLmheLRGAny for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 11:39:12 -0700 (PDT)
Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C391313179E for <tls@ietf.org>; Tue, 11 Jul 2017 11:39:09 -0700 (PDT)
Received: by mail-qt0-x244.google.com with SMTP id c20so106478qte.0 for <tls@ietf.org>; Tue, 11 Jul 2017 11:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:message-id:date:to:content-transfer-encoding :mime-version; bh=Ziubp72Q2SkUdXHZn3PtBnbNzs6A2dYVMDvtdVa8+6s=; b=gA6uCRL0FUQxbwt/UNSXdTmXqeGlTO9Lk64HO/l4ZEVeEA5YIRnpck8+8et5IM57aI aYGfv7DIDDU7CocomiWAmAA25IfTl2e2lzDLs377zLwMn2x1MZ//kzRuF2TkZ9n5lwpT SQpuumoe7qZ61YGXfEtgeAcrdfe4BppJfHEnuUChCfBvQf6hlpc22mvT+S3VIksTAzZh yeGEBuf8bcD6RQiBZIIfsRAMPdtLu3/Lbja/daNOcyqVSOIpGKy2Kl45RRzFmgtuE1Hc XVzXxZrxRr20V9+5sjrda/Lu4mfroAJP2GceXPWLQZuvOX0OxLOV3JsFunxJiVmvsNzM 355Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:message-id:date:to :content-transfer-encoding:mime-version; bh=Ziubp72Q2SkUdXHZn3PtBnbNzs6A2dYVMDvtdVa8+6s=; b=GxLgx8KIxYi+PKnh99aCmhZ9PBp1cF6r54IvkBzfcr+ZbyXXfgM5msMzESmplbKr57 ivj52uhtDkm42qrD4GNtj9Qhl7jBYjCCUAWdf6RYncc44/D2RNcGP2qadeHKtMAgYTnJ Y7/ecakApeXJlbQ/w7/pIegFA4t6yf+slA0ogqxEppF4OBXqL75bt8flsAexSt9dmLOq 7vdGGrLLmlJxV4gQI3Vm6KBqhpLAq/CO0KPZbZE6b33KZumHHKzvF9BEMVX/HNveCflH gosZX6XANqm3ldK6vIbICobVFcp4SIhI0Fv2SgKi53uQ8IcOEX6aTq4fsdD4uYcL73QC B9bA==
X-Gm-Message-State: AIVw110dD3mmsgufr4mXLafhwLyvlwdza4yKEbmhTZxhVX3O7tEOmLtc uPS+MVTChim1ULsiqYg=
X-Received: by 10.237.51.70 with SMTP id u64mr1689138qtd.211.1499798348705; Tue, 11 Jul 2017 11:39:08 -0700 (PDT)
Received: from [100.73.242.54] (236.sub-174-219-12.myvzw.com. [174.219.12.236]) by smtp.gmail.com with ESMTPSA id q40sm34043qtf.42.2017.07.11.11.39.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Jul 2017 11:39:07 -0700 (PDT)
From: Steve Fenter <steven.fenter58@gmail.com>
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPad Mail (11D201)
Message-Id: <D7648213-261E-4A26-BD6A-A5CB7F036D2C@gmail.com>
Date: Tue, 11 Jul 2017 13:39:08 -0500
To: "tls@ietf.org" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/OuhZZRBQzFpRfMc4EofbBg022Og>
Subject: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2017 18:39:14 -0000

Proxies in the Data Center

There are a number of reasons that inline proxies are not a scalable solution for monitoring communications in enterprise environments.

--  cost
--  production risk
--  latency

Here are some specific examples of where the use of proxies for monitoring communications is not viable:


Network Security Monitoring

Network security monitoring is not just monitoring traffic that results from communications with customers and partners.  All it takes is for one user to click on a phishing email and there is malware inside the enterprise.  Once this happens, TLS becomes the enemy, because 30% of malware is TLS encrypted, and any TLS features intended to thwart payload inspection work against the enterprise.

Malware does not always phone home out to the Internet on day 1 of infection.  Sometimes it does reconnaissance and lateral movement for a long time.  The longer this goes on undetected, the worse the situation becomes for the enterprise.

Microsegmentation is an attempt to contain this movement, but if the malware is TLS encrypted it will go right through the firewalls.  The answer to this problem is ubiquitous plain-text traffic inspection.  The scale at which this is needed can't be accomplished by inline solutions (proxies).  Traffic inspection is needed at the Internet, the Extranet, the mainframe, the WAN, DNS servers, email servers, wireless controllers, and a host of other locations.  Traffic inspection is also needed in the virtual environment, where all the virtual tools necessary don't exist yet.  My Seoul presentation documented 150 physical tap points feeding network security monitoring devices - and this footprint is growing.  There are too many inspection points to replace with inline solutions.  You simply cannot place a proxy between every system in the enterprise.

One other crucial point to this discussion is that endpoint monitoring doesn't catch everything.  The strategy of "Defense in Depth" says that the more layers of security infrastructure you have, the better your chances of blocking or identifying malware.  Network security monitoring is catching lots of malware missed by endpoint inspection.


Threat Detection and Incident Analysis

Threat detection inside the enterprise is not just receiving IDS or endpoint monitoring alerts.  Threat detection analysts need to track down the source of the infection, which could be anywhere within the enterprise, and the primary tool for doing this is packet capture with a decrypted payload.  Because the source of the infection could be anywhere, we need ubiquitous packet capture and ubiquitous decryption capability.  Again, inline solutions don't scale to the number of monitoring points needed for this level of visibility.

No only does an out-of-band solution like static DH allow many more permanent monitoring points with simple network taps, it also allows enterprises to deal with gaps in visibility.  If a needed flow is missing, we can set up span or mirror sessions, capture the packets, and decrypt them after the fact.  This can't be done when relying only on inline proxies.  Adding a new inline proxy is a multi-month or more project.  In the midst of an active attack/infiltration every minute is crucial and network re-architecture is not an option.


Troubleshooting

Enterprises provide services through complex, multi-layer applications and backend infrastructure.  Inevitably, there are bugs in these applications and the source of the problem must be found through troubleshooting.  Network troubleshooters need to inspect the packet payload in order to find transactions on the wire in environments where there is extensive NAT and extensive encryption.  Both of these are very common in enterprise networks, and encryption inside the data center is becoming  more ubiquitous over time.  NAT, by the way, is being used in large part not for IP address exhaustion, but to allow for multiple redundant paths.

Complex applications can have hundreds of application and infrastructure nodes as well as many tiers, any of which could be the cause of a slowdown or failure.  Often there are no log messages on any device giving a clue as to the source of a problem.  Troubleshooters need to be able to take a packet trace at any layer of the infrastructure and decrypt the trace in order to find the transaction of interest.  This tracing could be between physical devices, like between a firewall and load balancer, or it could be between VMs.  Tracing in the virtual space could involve tracing between VMs on different blades of the same blade chassis or between VMs on the same ESX host.  Since the root cause of a problem can be anywhere in an enterprise, this translates into thousands of locations in a large enterprise where troubleshooters may need to take a trace, decrypt it, and locate a transaction.



Inline proxy solutions add cost, production risk, and latency at every layer in which they are implemented.  It doesn't take very many inline locations before the cost is in the millions of dollars.  Because the solution is inline, lots of redundancy has to be built in, including multiple columns (doubling the cost), bypass taps for failure scenarios, and extensive procedures for troubleshooting and failover.  Bypass taps and TLS decryption appliances can and do fail, and when they are inline a production outage is caused, usually in a critical part of the network and affecting multiple critical applications.  Proxy solutions also add 1-3 ms of latency to every packet.  This is not a big problem at one layer, but when many tiers are implemented with inlien proxy solutions the latency adds up.