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

Ted Lemon <mellon@fugue.com> Tue, 11 July 2017 18:52 UTC

Return-Path: <mellon@fugue.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 4E3C813179F for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 11:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 UgqeIdKJubLk for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 11:52:00 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 58D5D131756 for <tls@ietf.org>; Tue, 11 Jul 2017 11:52:00 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id p21so836248qke.3 for <tls@ietf.org>; Tue, 11 Jul 2017 11:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zOH52o+5vADF8+aE14ekVhoLYKU+Owo/fR+P7j7cMyQ=; b=vjMtRzEuJQGKesbDatRi+k8Egy+N252OUXWfaeZevo+1bsQyhFQ2idG2ndXB7vc+wM Rr7DXPqzzVMGkgYiM/W9fL58NtmGCjfM5a9yIheqlg1Mu3zH5F1Ej1MCOSgFnQg5sksv TJSBT+3RfDagVQxOqiDSCVsbwzONRkzJiqd7IauyCafFH0t6C4d+qQXpDDJCEqQnEMXZ jWOBjPE1xvRhHU87WY24obA2w80SoNIHzPuGGr+vsviHaLG5TFdCqc7SMgiinrMV0wEj +TLwkbhFGrIufaU8YtwolTh1fp0FuLsVyrdz//+hJcsDPutR0f80zuICbrrTRaEVfFAN 1byw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zOH52o+5vADF8+aE14ekVhoLYKU+Owo/fR+P7j7cMyQ=; b=aZChKWap/6P9HLD/hpe/dDhiMKejRK5pQ0DnaCw0REOIrnEj/h6u5mqHXMs6aw7s51 JUsLfHS+S/Xxj9C4g0XX7pRBbIRmFtuUxpgUeE8VtGRKoBWlrvJw6gZ4fShn2ro8MMbe HLjXPrcou8oueIg0iksvyyXz4KfL55vu/KE7bRnFiIzrar8PBCvzswuLPWWBaHhRY7so 77f5Lc/ajdA2qspYdrEw/3intmVFFRFD88BNVTKPB+gCfRq/oUB1BXxAtXbY74VLQ8Wk amxvzDNZaXE30zdNPh2m7T/wqDrgp8aFgz+eIk6EaFB8aqvRMf0MjkSyC/a0mV/0+Kem Ushg==
X-Gm-Message-State: AIVw111O5dZLoriykycT2Ahmhb3XOdHYbAHvAsMV2ED97xJqPBm2m0A1 k3aEaZ4H8LXw6miv
X-Received: by 10.55.5.135 with SMTP id 129mr1767728qkf.184.1499799119289; Tue, 11 Jul 2017 11:51:59 -0700 (PDT)
Received: from macbook-pro-6.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id p24sm41470qki.49.2017.07.11.11.51.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 11:51:58 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <972BC031-5CE1-4810-B7DC-62CA3B7B60CB@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F002256-C6C1-490B-AC90-C4FE19F48A12"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 11 Jul 2017 14:51:57 -0400
In-Reply-To: <D7648213-261E-4A26-BD6A-A5CB7F036D2C@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
To: Steve Fenter <steven.fenter58@gmail.com>
References: <D7648213-261E-4A26-BD6A-A5CB7F036D2C@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EkG5eSTwFJiTY6NxAHkKZXykFco>
Subject: Re: [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:52:03 -0000

On Jul 11, 2017, at 2:39 PM, Steve Fenter <steven.fenter58@gmail.com>; wrote:
> 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.

I realize that you are making a substantive comment here and might not welcome a sales pitch, but FWIW there are ways of addressing this that don't involve examining each stream, and are likely as effective.   E.g., malicious domain redirect based on the domain name in the URL.   This is a lot cheaper than doing decryption and inspection of the contents of every TLS stream.   It also allows for other methods than payload analysis for detecting probably malware—e.g., pattern analysis.   I'm pretty sure that Stephen will tell you that this is an attack as well, and he's not wrong, but it has the virtue of not requiring that TLS be broken.

Also, please note that the proposal you are referring to does not solve this problem at all, unless the malware is already on a server on your network (which is the scenario you are describing).   If that's the case, why is TLS intercept the most cost effective way to detect this malware?   It seems to me that it would be a lot easier to just scan the file on the server before making it available for download.

Can you explain why that's not the right solution for this particular use case?

Also, although there was a lot of talk about how you need to do decryption-and-inspection rather than using proxies for performance, that actually just doesn't make sense.   Is it because the proxy is too close to the edge, resulting in trombone routes?   Otherwise I don't see how it could possibly be more efficient to decrypt and eavesdrop than to proxy.   Can you explain?

Sorry to hold your feet to the fire, but what you are saying here just doesn't make sense to me.

As for threat detection, again I'm not seeing how decryption and packet analysis is a win here.   Can you explain?

I see why it's helpful for troubleshooting, although again a proxy would take care of that.   But in any case, for the other two examples, it doesn't make sense even from a performance perspective.