IETF Logo Mail Archive

Re: [TLS] Breaking into TLS to protect customers

"Salz, Rich" <rsalz@akamai.com> Thu, 15 March 2018 11:10 UTC

Return-Path: <rsalz@akamai.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 9F7201270B4 for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 04:10:22 -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, HTML_MESSAGE=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=akamai.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 0qXjYqLRhcza for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 04:10:20 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719F51270AB for <tls@ietf.org>; Thu, 15 Mar 2018 04:10:20 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w2FB5axk001992; Thu, 15 Mar 2018 11:10:19 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=PAjwY3pMC/FYFDnqNNAcNOhUfbk2abT94W7agQqY7zg=; b=edqjbrv6/004zG0ra/iTg+//709iE9jyWVRU43mllouJCHGPaxEAlEs1cw9Ptp5JkiVn ywRr42h/zbfhqPeJtzyvoKrdyZraBXx7Q5fnZ00xy+5XmEUz8h9srbGNdaxYcBvGpkgQ kYr6YYaUaqHQel8VpYGwWDX0cbElj9Mp+CXJZcKS2WEYXw/pGWjPsUEOCDSi9u6KcRoi 0FzhLRiFAAG7ghuTJO6Pfj8kY1TOHAZh8qRCC43OWNNVG+xeRUYN8IhrrkOOlAqIlL2Z 5pZHM71Ywo3OcqkKMCjDDrlSh2fUkkAFlOMjtQrAi3V84h5HJQGZ8HqyveoQz4PCM9G1 vg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2gpmuywdbf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Mar 2018 11:10:18 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2FB6XNB028064; Thu, 15 Mar 2018 07:10:17 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2gmbjys7ym-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Mar 2018 07:10:17 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Mar 2018 07:10:16 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 15 Mar 2018 07:10:16 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Yoav Nir <ynir.ietf@gmail.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Breaking into TLS to protect customers
Thread-Index: AQHTvA3iixHTI7nuzEOVKDOY2Cg356PQ/0MAgAAk8AA=
Date: Thu, 15 Mar 2018 11:10:15 +0000
Message-ID: <F81530E8-CFBB-4688-AB56-67C003D7BCC2@akamai.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com>
In-Reply-To: <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.164]
Content-Type: multipart/alternative; boundary="_000_F81530E8CFBB4688AB5667C003D7BCC2akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150126
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150126
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/waSGKGxdpD71mPxbMSghC_hpDas>
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 11:10:22 -0000

If I am conflating them, it’s on purpose to draw out the differences.  I’m not an Equifax customer, for example.

The key point in my note is this: how would TLS interception prevent these kinds of things, given that interceptable TLS did not?


From: Yoav Nir <ynir.ietf@gmail.com>
Date: Thursday, March 15, 2018 at 12:57 AM
To: Rich Salz <rsalz@akamai.com>
Cc: "tls@ietf.org" <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<mailto: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<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email