Re: [TLS] Breaking into TLS to protect customers

Carl Mehner <c@cem.me> Thu, 15 March 2018 16:58 UTC

Return-Path: <c@cem.me>
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 15ED012D7F0 for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 09:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=cem.me
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 cucgxoqZT3Ya for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 09:58:55 -0700 (PDT)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 ACD64126D73 for <tls@ietf.org>; Thu, 15 Mar 2018 09:58:55 -0700 (PDT)
Received: by mail-vk0-x22c.google.com with SMTP id w197so3815038vkw.3 for <tls@ietf.org>; Thu, 15 Mar 2018 09:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cem.me; s=cem; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Px1ABpi6vupXHZjHbcKCo/YuFO0IDmLuCUmnNChmBBg=; b=eYNGsCjSWPCKOXp9kklikXn0x4gXpfTw5ArgzKierXIpc4mh++ss/9MiBh+pRjne/l T72Tm+Rg0fgTCOBxS+n8BIe7wxTfYgeG13D/QPbboBep+GA5Gux6MoxnA7r55/i2BccR eJAWjU0MVhk97gjjmnvf8t0iIZSjhZdIkpgz4=
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=Px1ABpi6vupXHZjHbcKCo/YuFO0IDmLuCUmnNChmBBg=; b=PvEIzN08QFv+kRToVrL1GEdCzpUylzAF32hQvisWAo0DK6XBn3UL418F6Q/+EoyuZg KIIuytjL3h4KkZs9bSbmi7Vw7bnIUzY/Rxk5IfyJitbsRYVqAs4cUEUn7pTY5sHDD/sM VkWopvTVR9qOIdrx1ZaXgK1a52ELdtj0hD07pTV+9OThhlIM6LPs6yTzAlzTsLrcOg3N 7+xVbsKPKV/k6OIbWIIN79SYBQ+oeWXMvIBtqGr7nlPhq3HUArSm78pElLZVyvtm65Xg Z/4+6nxGOPM29FioQmyd/cIEzNlT5RwtT5CN2j5t+pCcMZ0Mmuk4X5WQ/Zd4TwJCO6D4 5fFQ==
X-Gm-Message-State: AElRT7EWJdLQXrMf/157tQaPTZfrKN+vSPpLDOk+RpAqrljdXYoZAHm9 L4xURtWT0jUqRQ94xM7000Ax7Y7ZFZG8uN4FrUcLRZI1yi0=
X-Google-Smtp-Source: AG47ELv1Q8P1U/M5DUm6K/QXcD4msSi6SxDzkCDYTWN+aG0XP1yGfdeVevyB/0kBH8pAI59JLoYrcrrV4HQzEYYUoAs=
X-Received: by 10.31.125.200 with SMTP id y191mr1766028vkc.57.1521133134272; Thu, 15 Mar 2018 09:58:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.74.82 with HTTP; Thu, 15 Mar 2018 09:58:53 -0700 (PDT)
X-Originating-IP: [12.27.152.137]
In-Reply-To: <CAHbuEH7tF3CwxKdFBpC_6VKOX-TJ__u21GgtUKwBrRqfBW_aBQ@mail.gmail.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com> <CAHbuEH7tF3CwxKdFBpC_6VKOX-TJ__u21GgtUKwBrRqfBW_aBQ@mail.gmail.com>
From: Carl Mehner <c@cem.me>
Date: Thu, 15 Mar 2018 11:58:53 -0500
Message-ID: <CAEa9xj46VWWQzuHG0=s6pavaXMQ7=PFuKTWANhn_tmnRQ1rDJQ@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Ion Larranaga Azcue <ilarra@s21sec.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1494ac1ff0fa05677668f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XrsnBi9myzXvd2jEh7ptXSqun1U>
Subject: Re: [TLS] Breaking into TLS to protect customers
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: Thu, 15 Mar 2018 16:58:57 -0000

On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com>; wrote:
> I think what Yoav is referring to by detecting BOTS within the
> network, is really so called advance persistent threat (APT) actors
> that are moving around the internal network leveraging existing access
> rights of compromised accounts and privilege escalation
> vulnerabilities.  These might be detectable with 'visibility'.
> Patterns and behavior might be used to detect the APT use case whether
> or not encryption protects the stream, but it is more difficult.

Yes, they might, however, the best place for malware detection is on the
edge (which is out of scope for "in the Datacenter" type connections) and
the endpoint, where an agent is able to run that does not need to 'break
in' to the TLS session. Yes, the Fenter draft talks about how malware
endpoints can be anywhere in the network, and that they can delete logs as
a reason to require out of band network decryption. However, if "breaking
TLS" becomes an effective malware mitigation means, more malware makers may
move to using app-level encryption (as some already have). Therefore, the
conclusion we can draw is that malware is not a reasonable reason requiring
this enhanced "visibility".


-carl