IETF Logo Mail Archive

Re: [TLS] Breaking into TLS to protect customers

"Salz, Rich" <rsalz@akamai.com> Mon, 19 March 2018 16:52 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 C04F012E877 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 09:52:55 -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 bzXlUNwbRj_9 for <tls@ietfa.amsl.com>; Mon, 19 Mar 2018 09:52:52 -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 16C1612DA4F for <tls@ietf.org>; Mon, 19 Mar 2018 09:52:52 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w2JGm89p006299; Mon, 19 Mar 2018 16:52:50 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=hZNLUlzne4pOQENCLR/xXlre4J3CjDlWLZdjKeelogc=; b=jJbuucDD9IHgNuwANCVasDJco4pEq+2HIujHAUCIt8k8SrDFMw+RgCb5hRfAp7+v5F27 NMhUqRHuoNesIZhaIE90+x2BIvuCkQvrPdmb5VVau8qWLoKghk+aaF1WvLSPVM/3rEhw 4LAtYMmnPK34fYHjBOrdh8abv7vZwb5Fx5NXJJXm0MwfGdYm1+k4/r3YC2fpcs7LcCNl /mQBVIr8NY81NCDSGhn280Za7IHw+u1+MX7fwBiGZbunrGnbTlykQUfVhgn91AQtc2tD 8x8wUItXfy/xwd33ys6jx+juJ/TgqdjshK7NP2wWIwM6D9G5LCA8p10oLqrAWqGtR407 mA==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2grue6pq1d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Mar 2018 16:52:50 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2JGnUWp013787; Mon, 19 Mar 2018 12:52:49 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2grxbw56qn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Mar 2018 12:52:47 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Mar 2018 12:52:45 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Mon, 19 Mar 2018 12:52:45 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Ryan Sleevi <ryan-ietftls@sleevi.com>, Colm MacCárthaigh <colm@allcosts.net>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Breaking into TLS to protect customers
Thread-Index: AQHTvA3iixHTI7nuzEOVKDOY2Cg356PQ/0MAgABB+4CAAJuVAIAFluaAgABx+ACAACJLAP//xTaA
Date: Mon, 19 Mar 2018 16:52:45 +0000
Message-ID: <41BA916C-BC87-41A7-8D8C-5A81BA22FE66@akamai.com>
References: <C43EDAAC-1CA1-4289-8659-B2E05985F79C@akamai.com> <E22E3F4C-2A44-4F17-9FEA-18760C36A1E8@gmail.com> <0bd7ed2d174a45d993026c8ed0443ae8@LXDOMEXC01.ssidom.com> <6888195D-1AD6-45B1-8F77-AFA088CFF78A@gmail.com> <87y3iottae.fsf@fifthhorseman.net> <CAAF6GDeAOKtCF5BhfyG6wEd5L-mevKeuDMM1AmgdGKyfuEyzdQ@mail.gmail.com> <CAErg=HExeE0L3Lw4i2gEx3URVfci=RrODHBcVR_EF255R1FYvw@mail.gmail.com>
In-Reply-To: <CAErg=HExeE0L3Lw4i2gEx3URVfci=RrODHBcVR_EF255R1FYvw@mail.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.41.154]
Content-Type: multipart/alternative; boundary="_000_41BA916CBC8741A78D8C5A81BA22FE66akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-19_09:, , 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=791 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190188
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-19_09:, , 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=730 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190188
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZstzRyUdxl0prJknu0nGhIOOpKc>
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: Mon, 19 Mar 2018 16:52:56 -0000

  *   It's difficult to speculate here about the potential impact, but isn't another possibility that it would legitimize a mass-market of such products, particularly if such capabilities were introduced into clients and browsers?

That is definitely a goal. The people who are in favor of this, want commoditized offerings so that they can get it more cheaply, standardized, and with much less effort and expense on their part. Last time, I pointed out that this clear-text signaling could be used as additional leverage by captive portals (my example was passengers on a plane with inflight Wifi).

If I were really twisted, I could imagine ISP’s (or operators) requiring this to put customers in the “high speed lane” or traverse a Big Firewall. Of course, purely for efficiency.

v2.23.0 | Report a Bug | By Email