Re: [TLS] Breaking into TLS to protect customers

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 15 March 2018 17:43 UTC

Return-Path: <kathleen.moriarty.ietf@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 45C9212DA14 for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 10:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 B7ZMCNxNoqK1 for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 10:43:01 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 B9C2012DA09 for <tls@ietf.org>; Thu, 15 Mar 2018 10:43:01 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id u5-v6so10207193itc.1 for <tls@ietf.org>; Thu, 15 Mar 2018 10:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Z2Vj/UVjSwG/WAso5GRvN7gs41wDOek3Cr/csWx1EI=; b=bL3e0vyFkxYbDbKIY/DiIPTeDy0JUztxR3QTm4Q16r1/USlXAM5CkBEIyudNLATwnJ ciburutcifIzyEMeHNFU8DOCMHhd6FluZA+rf2lSC+zFMc5OGMT89n4K9CvIHcKprHDC 9I2vxXE36jdlsiMBa6mCRZvgOBZVZLP090t2gpZyOuWhn/oKqiBXaOIzUmRAh0EBHutO yPylTGWi7anJ+Lj2i4iXFWD6uV841SZbu8mX5Rt/MyDEMy3dPt0IB9mpEjcYVogDngrE lJfRxyEXkxghJ3Hic06AINoEegtswPelzmLUz+0WyHmh8Kzj7RL0SDCNI7/lN2L3aFcU Gy3w==
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=7Z2Vj/UVjSwG/WAso5GRvN7gs41wDOek3Cr/csWx1EI=; b=Oz7vRLHxKrxjV6DXD0Ni2MFa+S3jnaVEqc1MKHG1aM/68CgaSNtfj4vckpYjT9j6DN zFPDBSvsJQwR2P5VBB+wpX6J+7UfI1T2jpen+EfJz2dbXPXBLnsmupJ3aKSyhQYVUsmP RaZ0Hrgdx7tjU4cpXnW0uLaUYzm+CuDmrO+cV1vj1yQVmg3x4wIuPe6K+JV3khYkNpWl QFPn1XnodZyiTQ0TXh5ZVamLGlM18+KQ3T0V1DA08aRIuBFVdAxv/OwGp64Z2yX75ZD6 1YYY9W+uCKNqqpEZ/8rQ4GceGmnHpRgWtvHdmlHiqUc22ejNl1myGNmXTPSYnaahtc3T afvQ==
X-Gm-Message-State: AElRT7HJuu0dLfAhjg8Nh12sjGPZrT40nQGTECRxYpN2Wu480cp63vOr h/aCwtc1Zj6N55MubVIdcYZ8Hzl9iesj7nLA2nE=
X-Google-Smtp-Source: AG47ELuYOtiMnoxh8Bvd0FcZZUbrjE5hzBD0cH3SAJ6VDCV/MTVwo+8+axB4mDK0CVEqGiRqHruJf+XyGHXCMuPER10=
X-Received: by 2002:a24:3c8a:: with SMTP id m132-v6mr7462638ita.132.1521135781068; Thu, 15 Mar 2018 10:43:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.156.137 with HTTP; Thu, 15 Mar 2018 10:42:20 -0700 (PDT)
In-Reply-To: <CAEa9xj46VWWQzuHG0=s6pavaXMQ7=PFuKTWANhn_tmnRQ1rDJQ@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> <CAEa9xj46VWWQzuHG0=s6pavaXMQ7=PFuKTWANhn_tmnRQ1rDJQ@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 15 Mar 2018 13:42:20 -0400
Message-ID: <CAHbuEH4hoTfzWSvx0RL48wX8tBCKuXT5wc2ebCGxB3WN53hyyg@mail.gmail.com>
To: Carl Mehner <c@cem.me>
Cc: Ion Larranaga Azcue <ilarra@s21sec.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4VlmsLfrizuIUNo0UJpfU9oHSF0>
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 17:43:03 -0000

On Thu, Mar 15, 2018 at 12:58 PM, Carl Mehner <c@cem.me>; wrote:
>
>
> 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".

The example I provided is not about malware, it was about lateral
movement by threat actors within a network.  The initial compromise
that led to access within the network may have been through malware or
some other vulnerability, but I do think monitoring on an internal
network (encrypted or not, through logs or on the wire) is the use
case for attack detection that is plausible with the proposed
approach.

Best regards,
Kathleen

>
>
> -carl



-- 

Best regards,
Kathleen