Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

"Salz, Rich" <rsalz@akamai.com> Wed, 14 March 2018 13:42 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 5A9EA12D775 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 06:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level:
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wvajU5ittqTq for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 06:42:28 -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 171DC12D0C3 for <tls@ietf.org>; Wed, 14 Mar 2018 06:42:28 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2EDb6Ir018550; Wed, 14 Mar 2018 13:42:24 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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=SZ2ObpYgjiC+LtVwpG3dcyEyCrY8SYWN+Q1fJaNZeqU=; b=cE2GnNh4pgmSMfkCbwraKoreXBapzXTdS91fa0a+3VrSIUVJXa3/HOtPc/kkzBehAXma yYmonfVGcbRwxwgaZLowynLkgSmEiQ5/O90VSlTRHnKsRtYTnkTq4GBqNGKhD7BmKh8x FZ6Z1jHZkKkT/7EeekitdMucESN2BQ+/lSPT50zRk47L+w5pVaO7kWmcyulHC4SMfKa2 jYXGn0zopx57Ubhz4btmznnaIOsrYZ4y4r6foioC39/ITWHpDZSQ8RkvNXkNyvta6FB4 yLiIrSl39FwFO67yHrnlBPLDfapbkYtpvk+So0I5NDfkoGjsavd2+1T+nZMSVU6xxTbK cg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2gpjrh27vm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Mar 2018 13:42:24 +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 w2EDfwIZ000612; Wed, 14 Mar 2018 09:42:24 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2gmbjynxph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Mar 2018 09:42:23 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Mar 2018 09:42:23 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Mar 2018 09:42:23 -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 09:42:23 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Martin Thomson <martin.thomson@gmail.com>, Russ Housley <housley@vigilsec.com>
CC: IETF TLS <tls@ietf.org>
Thread-Topic: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)
Thread-Index: AQHTu3E/vxrzKY2eGU+X0cwp6J3VjqPPvawA
Date: Wed, 14 Mar 2018 13:42:22 +0000
Message-ID: <99D1D595-F5FA-439B-A7EF-882F82EF587E@akamai.com>
References: <CABkgnnUiQsCtQ+u_-yAg90FkLOM96PunqoeyeOP-9AvJhpdtPw@mail.gmail.com>
In-Reply-To: <CABkgnnUiQsCtQ+u_-yAg90FkLOM96PunqoeyeOP-9AvJhpdtPw@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.39.128]
Content-Type: text/plain; charset="utf-8"
Content-ID: <AE530763BEED8441BBE21FF48FB5DC8A@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-14_07:, , 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-1803140157
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-14_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=941 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803140156
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2vfnPX3TJmu0-Seg2u-R5j_qC4o>
Subject: Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)
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: Wed, 14 Mar 2018 13:42:29 -0000

>    So aside from enabling MitM, this also enables session resumption by
    the decryption service, something that the security considerations
    neglects to include in its list.

So I think this is an important point.  I assume the authors did not realize this. That shows how hard, and risky, it is to get this right.  In the US, we have been having arguments where the national police force (FBI) is insisting that tech companies can create a "golden key" that only they can use, and the security people are saying it is impossible.  This seems like another instance, no?

Oh heck, let me ask the uncomfortable question:  Russ, did you know this or was Martin's point new to you?

	/r$