Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Benjamin Kaduk <bkaduk@akamai.com> Wed, 18 October 2017 17:41 UTC

Return-Path: <bkaduk@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 42EF7133079 for <tls@ietfa.amsl.com>; Wed, 18 Oct 2017 10:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 72bCIehQyg5t for <tls@ietfa.amsl.com>; Wed, 18 Oct 2017 10:41:34 -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 E77831270AB for <tls@ietf.org>; Wed, 18 Oct 2017 10:41:33 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9IHaPve031336 for <tls@ietf.org>; Wed, 18 Oct 2017 18:41:32 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=IqQmdkfM3/gszPZeUPkDr2otzCigMr/3ELROKjciXOE=; b=pLYB2rEJ4l/2Ui2U25/S/sNRI8nx+XCpssAUoGvp2aOYLaz2pjW5EANP25H9WnYrX67G Zt+/iqW/T0gn98YJB0mb4qaGYXLZLEgBMJ/fQOjmlZS3yrLal0R7b8t694EmgunIJhMQ RRVcOw28yOues9xYunI84g2I8LVOd4Lu3iyJtFbTS2/LmiCUXOtt6YWHBuQTgUKIhpRs PsrJ2lGmxvZZbxQD1k9AkP2LxstliAZ2nvPICzUp5YN4CorsD6RGeS17lZTITopAP/Fd 3DagPhLbv/cZU8MrncU2jJXl0sN6mj27KRWDrcxXgM3Np6Ji5ejoxas7OqNXCSLv1j4J Ig==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2dpa0cra4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Wed, 18 Oct 2017 18:41:32 +0100
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 v9IHf24l012595 for <tls@ietf.org>; Wed, 18 Oct 2017 13:41:31 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dkdwucr9r-1 for <tls@ietf.org>; Wed, 18 Oct 2017 13:41:30 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id CE7041FC71 for <tls@ietf.org>; Wed, 18 Oct 2017 17:41:30 +0000 (GMT)
To: tls@ietf.org
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com>
Date: Wed, 18 Oct 2017 12:41:30 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-18_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180243
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-18_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=13 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180242
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cvIdq6lGfW6-MRmqJWbKURj6wSo>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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, 18 Oct 2017 17:41:35 -0000

On 10/02/2017 03:31 PM, Ralph Droms wrote:
> We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on the wire that visibility will be enabled for the session.  The new mechanism does not depend on static handshake or session keys.  
>

This draft does not seem to have anything to address the concern that,
once a visible ClientHello extension is needed to enable wiretapping,
certain parties (e.g., national border firewalls) would reject/drop
*all* ClientHellos not containing that extension, thereby extorting all
clients into "opting in" to the wiretapping and effectively rendering
the "opt-in" requirement useless for those clients.

As a more general comment, I think that this concern is so squarely at
odds with the concern that the client must be able to opt-in to the
wiretapping [and, optionally, be guaranteed by the key schedule to know
when wiretapping is happening] that I do not see any potential for a
workable solution.

-Ben

P.S. I agree with Rich; can we try to defer these conversations until
after 1.3 is actually published?