[TLS] Breaking into TLS to protect customers
"Salz, Rich" <rsalz@akamai.com> Thu, 15 March 2018 03:29 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 A8BAC12D86A for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 20:29:59 -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 (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 ee4YX7uFBHjS for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 20:29:58 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 D626912D82F for <tls@ietf.org>; Wed, 14 Mar 2018 20:29:57 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w2F3Rec5026565 for <tls@ietf.org>; Thu, 15 Mar 2018 03:29:56 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=x8Lv8mI3jJrGI/UNZYTydX9v83jdaw0Wh/0SvdKp1Ko=; b=DnLVXrur689c0YZ/UiB9zZQAU6FIKw+zgpSZyLq85IuefYdKciRNNICKSglPkHIOC+x+ xRJGcJo3gGdvysIAvI2QKGwfxPvpuCEzy7K2p/00DOAB9TQXsies8ttlrbupa0BIiU4r HEQl7/L89eA/xUGh8Xenq3GtFhdUZR54zXVJqwbUFFPH0NoOBpwZJIISKr1cX3mJrk+s gfkHog4F7ExZElb7vYAj7RWD1wNJ3dyt55Cyftguo1U+7ii7csJe03bQoLwbGB87l7ZR 7z4IuzKFLfeo8caZcZPm7SsJ5IyyJwjXXflOboWSZGxg+vdGAZdmDvN0DaiqHEKJM6Q9 ZA==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2gm5agwsck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Thu, 15 Mar 2018 03:29:56 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2F3QDEc017485 for <tls@ietf.org>; Wed, 14 Mar 2018 23:29:56 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2gmbk1cppp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Wed, 14 Mar 2018 23:29:55 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Mar 2018 23:29:54 -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; Wed, 14 Mar 2018 23:29:54 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Breaking into TLS to protect customers
Thread-Index: AQHTvA3iixHTI7nuzEOVKDOY2Cg35w==
Date: Thu, 15 Mar 2018 03:29:54 +0000
Message-ID: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.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.41.175]
Content-Type: multipart/alternative; boundary="_000_C43EDAAC1CA142898659B2E05985F79Cakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_01:, , 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=544 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150038
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-15_01:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=484 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150038
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cE75LU07QPx0WppDgXZxh9QDPV4>
Subject: [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 03:30:00 -0000
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] Breaking into TLS to protect customers Salz, Rich
- Re: [TLS] Breaking into TLS to protect customers Artyom Gavrichenkov
- Re: [TLS] Breaking into TLS to protect customers Yoav Nir
- Re: [TLS] Breaking into TLS to protect customers nalini elkins
- Re: [TLS] Breaking into TLS to protect customers Ion Larranaga Azcue
- Re: [TLS] Breaking into TLS to protect customers Salz, Rich
- Re: [TLS] Breaking into TLS to protect customers Kathleen Moriarty
- Re: [TLS] Breaking into TLS to protect customers Carl Mehner
- Re: [TLS] Breaking into TLS to protect customers Kathleen Moriarty
- Re: [TLS] Breaking into TLS to protect customers Ion Larranaga Azcue
- Re: [TLS] Breaking into TLS to protect customers Yoav Nir
- Re: [TLS] Breaking into TLS to protect customers Roland Zink
- Re: [TLS] Breaking into TLS to protect customers Ackermann, Michael
- Re: [TLS] Breaking into TLS to protect customers Darin Pettis
- Re: [TLS] Breaking into TLS to protect customers Eric Mill
- Re: [TLS] Breaking into TLS to protect customers Matthew Ford
- Re: [TLS] Breaking into TLS to protect customers Daniel Kahn Gillmor
- Re: [TLS] Breaking into TLS to protect customers Joseph Lorenzo Hall
- Re: [TLS] Breaking into TLS to protect customers Yoav Nir
- Re: [TLS] Breaking into TLS to protect customers Colm MacCárthaigh
- Re: [TLS] Breaking into TLS to protect customers R du Toit
- Re: [TLS] Breaking into TLS to protect customers Ryan Sleevi
- Re: [TLS] Breaking into TLS to protect customers Benjamin Kaduk
- Re: [TLS] Breaking into TLS to protect customers Benjamin Kaduk
- Re: [TLS] Breaking into TLS to protect customers Salz, Rich
- Re: [TLS] Breaking into TLS to protect customers Eric Mill
- Re: [TLS] Breaking into TLS to protect customers Benjamin Kaduk