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

Ted Lemon <mellon@fugue.com> Wed, 12 July 2017 01:22 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 67AC712EC1B for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 18:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, 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 tgFdZQDobRyy for <tls@ietfa.amsl.com>; Tue, 11 Jul 2017 18:22:21 -0700 (PDT)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 615EB126D73 for <tls@ietf.org>; Tue, 11 Jul 2017 18:22:21 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id q85so4505259pfq.1 for <tls@ietf.org>; Tue, 11 Jul 2017 18:22:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l3WWieATL/ScM+ZzQsQiaXRS38+67et2/F4U0D8aE30=; b=Uo14x4Do88q8+Y3t6Szw/gs9Vh9GELZ1hgeCKtWluMheaeRm3EZNIBdX0nRlCikK6o Kkh4Ofah2PcLSuBzYlv+8foXYeafAu/O0eFEyCwanITgspR6mSUzXwxU9q3HI0rRzFVI 2OeR6ohnmNCnmQ80g7FlYjlaudUGMHK65l/YY/qd4q2Bnmqr9/tzUaRGLEkMDFFGeE1b Wjh4Wxbym5ijV3MVJF1abWW/iATd+bXBw7W0hlkJIna+bC+LEsw3x7V7UqWfadrksVFx /+ilZ/N7Xy3eXej7iK8pJpMQ4fVSaPgZJsMs2Us7T6/aexpk7KZgPrhmztx6jYxQWorj 8f+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l3WWieATL/ScM+ZzQsQiaXRS38+67et2/F4U0D8aE30=; b=keriNoRhFpatMg7rVThO9s29uOJuCcEzXAqdRQXUXnUUjSaF3ClKB2rLDLXG/azM// wOnC7eahU2CwI0gNUgJ9gk7FNB6T+XDoQxyTNz0IeK9SmDG9jkDLT3Dw+dTiRzrnabTK 0bWatTzJMTufju8jCO/AehiyABQnew2PhT/LV+GCn/9DTYPiWUnTHhA5qdFJorOTcNwm 9HkgYf1t3YDNFDy6tHod0xc+yva3eyDh2selJ8HhHYHaT1tQDn6v6YpIGxJqkgqQMzmW DqLnVSCNNwav+X3OqZLIWIvvifADfetdHqO0r4t1cn/x+W2Y5UV0p9ybS7zeR5S777Cy yzAQ==
X-Gm-Message-State: AIVw112W3i5/SaDhQ4+HV3BEfGJVD8m7QLs2vbcpUGJ6DKM1ZmexePtr f1usNK6/ozk7+Dw28dAvNIrfQHRAatTK
X-Received: by 10.84.192.131 with SMTP id c3mr1409573pld.9.1499822541038; Tue, 11 Jul 2017 18:22:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.170.2 with HTTP; Tue, 11 Jul 2017 18:21:40 -0700 (PDT)
In-Reply-To: <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com>
References: <D7648213-261E-4A26-BD6A-A5CB7F036D2C@gmail.com> <e0f078a7-5ef7-7cd2-8e88-dceea13638e7@cs.tcd.ie> <2F25802B-195C-47A9-8270-5EF487A1F925@gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 11 Jul 2017 21:21:40 -0400
Message-ID: <CAPt1N1nAHZOnDngzvoUJ+iG9hTehbcn3ZEZEUbbSeub5yyJ3UQ@mail.gmail.com>
To: Steve Fenter <steven.fenter58@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c189e98c8fe6a055414a5fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7O0s2EBNHHkkljdmJEZ0mK64ieM>
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: Wed, 12 Jul 2017 01:22:24 -0000

To paraphrase (and forgive me for being a bit brutal here), you have no
basis for what you said other than handwaves and something from a Cisco
marketing presentation?

That is, "the odds are better if..." is a handwave, and not clearly true.
"Malware could be caught ... with multiple inspection points..." is only
true if those inspection points are able to detect the malware.   Phoning
home is actually pretty detectable using DNS snooping--you don't need deep
packet inspection, and it's orders of magnitude cheaper.

On Tue, Jul 11, 2017 at 7:59 PM, Steve Fenter <steven.fenter58@gmail.com>;
wrote:

>
>
> > On Jul 11, 2017, at 2:15 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>;
> wrote:
> >
> >
> > To add to Ted's clarification requests:
> >
> >> On 11/07/17 19:39, Steve Fenter 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'd appreciate a citation for that 30% figure.
>
> 30% came from Cisco Systems at a recent Cisco Live conference.  Their
> numbers indicated 10% in 2015 and 30% today
> >
> > 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.
> >
> >> Malware does not always phone home out to the Internet on day 1 of
> >> infection.
> >
> > In what circumstance will malware phone home to a TLS server that
> > is playing your wiretap game? That seems utterly illogical but
> > maybe I'm missing a reason why someone's malware will use TLS to
> > talk to a server that is controlled by the victim network as part
> > of phoning home. Please clarify.
>
> Phone home would have to be caught by an inline solution on the way out
> the Internet.  I was just suggesting that malware could be caught earlier
> in the process with multiple inspection points throughout the enterprise.
> >
> > S.
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>