Re: [TLS] Breaking into TLS to protect customers

Darin Pettis <dpp.edco@gmail.com> Sun, 18 March 2018 16:09 UTC

Return-Path: <dpp.edco@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 088D212EAB3 for <tls@ietfa.amsl.com>; Sun, 18 Mar 2018 09:09:23 -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, 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=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 uuR_2HWr1n_1 for <tls@ietfa.amsl.com>; Sun, 18 Mar 2018 09:09:19 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 EC95C12D94A for <tls@ietf.org>; Sun, 18 Mar 2018 09:09:13 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id y127so9012364vky.9 for <tls@ietf.org>; Sun, 18 Mar 2018 09:09:13 -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=f434NoOVcXgyWuFA1qIUQsmToBeh4tEnjaefTlXBb10=; b=XtZicvrFmmCLTYWtjkBjAKZGORcUSUOA53R0JMtodo8JVOyEgRSM0cOHvNZIyDG7eL lCvUwh/UgCOD5SRf3EiV5f+ZkM3vXNVHitxZ5VU1aTFX3Qk6kPyKvNdO5I/Zwifl0kRV Ji3bHyWb3kGhBa5ULt5bdkPofBDneh9iPwtQBJ/ChCfbMY0hlZ8WzION11NtlwQlQ3sw EMgKGWeaw5iq/Fi4pjX/McKVzndQWGvDU1v0cTH0To6vKVxavLjqydvjgisitz69uYn5 SGLtZ0Ot65h+Hy2UlOQ2eYTde+40j7WlG0WvsgkKUHuJp6GgOxAaAwUOBf9Vqk0/mi3P j+1g==
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=f434NoOVcXgyWuFA1qIUQsmToBeh4tEnjaefTlXBb10=; b=tTx4YOlqqCDnne1AF/a5BC5WxkRdpxpp1rSgMasCXQq/963n1sQgH0e+Wsai5zf3Wv oEFcwvTryuS8fYpJO2Wm4Mb4cUdj4kX3uebNEnXN6Ae4gmrTB95pU6j6IxuO4WboXiKV 8pqpo+ArhUZBJf0BjzEInbEvtjHZemHqKBBsqdFuugvgKu6gf16ebec2eMC8ryqxrCZc w5S/jcMarb0FKoenEfrFMpRHX6K0pyZsrqB19Jx+U/jsWV/ikuiR5HwLcLOuiZTXiJBN QnreHJ5B39wo5B3bzI2CvEy+zAEfUclH7AjpPfeDRpRQfIC9Muh67eihNnkY5RaxJ3tQ CNXA==
X-Gm-Message-State: AElRT7HY65cl8gES0C6gfqcyA46xV0nV4nLtJDdqmCP21HV8PwHYfgLN +t3UnqeE4775OxvkJ/ezHAceYsfuGM0VWwSf7pU=
X-Google-Smtp-Source: AG47ELsDKkxfMRstfC15gnIPhrZxVRWrOzXw/mmZhAo4n1NTyFdu9dtoxfICtl65I4NxMeJ6MiFVlqayj/DYRqHGHGw=
X-Received: by 10.31.216.71 with SMTP id p68mr5762763vkg.194.1521389352832; Sun, 18 Mar 2018 09:09:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.222.146 with HTTP; Sun, 18 Mar 2018 09:09:12 -0700 (PDT)
In-Reply-To: <BN7PR14MB23698A785363CC424A981A15D7D00@BN7PR14MB2369.namprd14.prod.outlook.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <BN7PR14MB23698A785363CC424A981A15D7D00@BN7PR14MB2369.namprd14.prod.outlook.com>
From: Darin Pettis <dpp.edco@gmail.com>
Date: Sun, 18 Mar 2018 09:09:12 -0700
Message-ID: <CAPBBiVRJRNi3oQCPbv0mn82nvgMXcF6VosOS8-GTB0xebxG4Hg@mail.gmail.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, Rich Salz <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114eccc2f0d4a90567b20fe5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xnepmyFXAQJoUGj2lqU1ovpLHv4>
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: Sun, 18 Mar 2018 16:09:26 -0000

Agreed.   I know a lot of good work has gone into TLS 1.3 and having
visibility to the data once it hits the data center seems like a new
capability to the good folks working that have had TLS 1.3 in mind for the
last couple years.   But to enterprises, they have visibility to their data
today and have become dependent on that visibility to utilize security and
troubleshooting tools.

This actually speaks to the fact the there is a different use case for the
Internet vs the data center.  Hopefully we can agree on that point.

On the Internet, data is transitory in nature and the focus of E2E
security.   Conversely, when the enterprise is the actual recipient of the
data, there is an expectation of security and performance of that data.
 If anything happens to that data, then the enterprise is pointed to - so
we need to see the data to run the needed services.  Initially regulated
companies have been pushed to encrypt internally which then in-turn
requires that data must be decrypted for tools and a select group of folks
can provided the required services.

Additionally, bad actors will have the ability to utilize TLS 1.3
decryption for command and control and data exfiltration purposes.
Security services need to see the data to combat that.

Finally, I wanted to make the clear that we utilize the term "visibility"
because it is the correct term for the outcome that is needed - regardless
of the technology solution that enables it.  Not to inflame anyone at all.
I know it's a contentious issue but appreciate everyone's input and
thoughts to come to a solution as pushing this to another technology or WG
isn't going to solve the current problem in time.  Kuddo's to EDCO for
sharing in both directions.

Thanks,
Darin

On Thu, Mar 15, 2018 at 2:50 PM, Ackermann, Michael <MAckermann@bcbsm.com>;
wrote:

> Good point Yoav.
>
>
>
> And this positive side effect holds true in the health care and insurance
> industries as well,  and is not an accident.  It is one of the primary
> reasons this monitoring is performed.
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Yoav Nir
> *Sent:* Thursday, March 15, 2018 12:58 AM
> *To:* Rich Salz <rsalz@akamai.com>;
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Breaking into TLS to protect customers
>
>
>
> Hi, Rich.
>
>
>
> You are conflating customers and users. The customer that may be protected
> by breaking TLS in a bank’s server farm is the bank itself. An IPS system
> with visibility into the traffic may detect bots that are there to steal
> data or mine cryptocurrencies or whatever.
>
>
>
> If the customers of the bank are protected, it’s a happy side effect
> (collateral benefit?). The object is to protect the system integrity and
> the data.
>
>
>
> Yoav
>
>
>
> On 15 Mar 2018, at 5:29, Salz, Rich <rsalz@akamai.com>; wrote:
>
>
>
> Some on this list have said that they need to break into TLS in order to
> protect customers.
>
>
>
> The thing customers seem to need the most protection is having their
> personal data stolen.  It seems to happen with amazing and disappointing
> regularity on astounding scales.  Some examples include
>
> ·         retailer Target, presumably subject to PCI-DSS rules
>
> ·         Anthem health insurance, presumably a regulated industry
>
> ·         Equifax, a financial-business organization (but apparently not
> regulated)
>
> ·         Yahoo, a company created on and by and for the Internet (one
> would think they know better)
>
> We could, of course, go on and on and on.
>
>
>
> NONE of those organizations are using TLS 1.3.
>
>
>
> So what kind of “protect the customer” requires breaking TLS?  And what
> benefits and increased protection will customers see?
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>