Re: [TLS] Breaking into TLS to protect customers

Eric Mill <eric@konklone.com> Sun, 18 March 2018 22:21 UTC

Return-Path: <eric@konklone.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 0871512D7EF for <tls@ietfa.amsl.com>; Sun, 18 Mar 2018 15:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=AJKLbTNI; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=m1c2G+S1
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 U2oYmgfLKE4C for <tls@ietfa.amsl.com>; Sun, 18 Mar 2018 15:21:02 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6362126B72 for <tls@ietf.org>; Sun, 18 Mar 2018 15:21:02 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 72ABAC2197 for <tls@ietf.org>; Sun, 18 Mar 2018 18:21:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=X1XjKz6YQ+L6ySvKol27tQEEJh8=; b=AJKLbT NI/+9mVBs8dcduOmXt8I0offg6W7rMvaMSs52owSzHjfiyx62aqWrKL4Dlk2ESHf S5dDbwgtKiQCL9Jesfea5+hOIR435MLyCCmyAitWeV91xYbIl97P6xKMPLLM2OxB aB3aCb7v7/Dr2+W0eCTzBNmMohYczmYRLKJ4w=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 3571FC2196 for <tls@ietf.org>; Sun, 18 Mar 2018 18:21:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=z2+v77s3TWnWFKz38GtORFhcrZPkebvIDFQC/GPPobQ=; b=m1c2G+S1vn9b8zeM3N5cr0+1WAudeBBxMgr1XqjtE3BizN4pduUFB/911ZjrGY7Tv7SSyHTks90FkBLh56Ud1RID38mk4EtlX6e/Ch+olkPBTTVWeRZ7Ka1j668ztvQqOLqq/ncHsTDX5s49z77BP3sKyiFRtHLMDGvaDPjbBf0=
Received: from mail-io0-f180.google.com (unknown [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 5A680C2195 for <tls@ietf.org>; Sun, 18 Mar 2018 18:21:00 -0400 (EDT)
Received: by mail-io0-f180.google.com with SMTP id l12so18479901ioc.10 for <tls@ietf.org>; Sun, 18 Mar 2018 15:21:00 -0700 (PDT)
X-Gm-Message-State: AElRT7GBZs9wSnUceJDFp5OCyiXLjZKgqfG/zeIN3Vd3+3N+knIwp+yv 5YUQSjsmK0oKRU9BIurOAEVU36OYQ0ZFuVK64Ys=
X-Google-Smtp-Source: AG47ELsFGTbHkP2sN5pkachIJazhfeIiclJ4+8/x+c/EX2TU0yRXpgzIc1uCL7iDtqxyY90RhZmsWfvZJgQxJ64ZFLk=
X-Received: by 10.107.202.67 with SMTP id a64mr10182910iog.194.1521411659678; Sun, 18 Mar 2018 15:20:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.189.130 with HTTP; Sun, 18 Mar 2018 15:20:19 -0700 (PDT)
In-Reply-To: <CAPBBiVRJRNi3oQCPbv0mn82nvgMXcF6VosOS8-GTB0xebxG4Hg@mail.gmail.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <BN7PR14MB23698A785363CC424A981A15D7D00@BN7PR14MB2369.namprd14.prod.outlook.com> <CAPBBiVRJRNi3oQCPbv0mn82nvgMXcF6VosOS8-GTB0xebxG4Hg@mail.gmail.com>
From: Eric Mill <eric@konklone.com>
Date: Sun, 18 Mar 2018 18:20:19 -0400
X-Gmail-Original-Message-ID: <CANBOYLUp4WhiW++7VsXRu5nyz1Th0Q+FnYOgZZZSAok6BfBQoA@mail.gmail.com>
Message-ID: <CANBOYLUp4WhiW++7VsXRu5nyz1Th0Q+FnYOgZZZSAok6BfBQoA@mail.gmail.com>
To: Darin Pettis <dpp.edco@gmail.com>
Cc: "Ackermann, Michael" <MAckermann@bcbsm.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0bd56288489c0567b74180"
X-Pobox-Relay-ID: A3401F98-2AFA-11E8-9129-67830C78B957-82875391!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3FZKJbHkiUvIc0vXPIdWCSfGHLQ>
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 22:21:06 -0000

On Sun, Mar 18, 2018 at 12:09 PM, Darin Pettis <dpp.edco@gmail.com>; wrote:

> 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.
>

We maybe can agree that enterprises feel they have become dependent on
their current set of security and troubleshooting tools, which rely on passive
decryption for visibility. That doesn't mean that that the enterprise is
actually dependent on that current set of tools.


> 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.
>

Passive decryption is not necessary to do this. Active
decryption/termination can also accomplish this, where all outbound network
traffic is required to pass through trusted proxies -- an active approach
is necessary anyway to actually stop data from being exfiltrated.
Presumably stopping the data is superior to just being able to see it
leaving later when looking through forensics.


> 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.
>

Totally agree, though it's still not obvious why the tools to enable this
don't already exist.

-- Eric


>
> 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
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>