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

Benjamin Kaduk <bkaduk@akamai.com> Fri, 03 November 2017 20:34 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 062F113FFB7 for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 13:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MAHan-o0J7zq for <tls@ietfa.amsl.com>; Fri, 3 Nov 2017 13:34:27 -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 9816613FFB3 for <tls@ietf.org>; Fri, 3 Nov 2017 13:34:27 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA3KXBt5009610 for <tls@ietf.org>; Fri, 3 Nov 2017 20:34:25 GMT
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=b6nKkj3ic0wfrPEiNANIM4Ak4UPaQVws7+4hfKrK6bg=; b=OoDg8t1Zez6HxFMVCxaMZ1eP89dSCgln0FLyNEI/Rlh9HpCZAxL5MTekYje30hRbogGk P/OSpvVPkW4010yR/eyKxpXkp9V0ggjAMtxX49z0MgrdRv+JhmWhT9Lw1JTNQNnpKxwW 4lZoDtle3eWUSV+bSJmk1PzrO64MR6/H/Nix5B4OfPwGnyAqyKn9TjSTcEBw57PJffH8 b0n6y1LXpzb5fw4eUWBNASF+1fvcWw/Ers/ADXdF+7umX8BdlmcHU2yvf01BdJSF2E/Z yEJCur16Zw1HvZ0gXRhy3VCEXRywlGldkH06UzaURteCVnH/rv8Jb8fxuauzUBY56vSa cg==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2dyu0d7092-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Fri, 03 Nov 2017 20:34:25 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA3KVV4U020253 for <tls@ietf.org>; Fri, 3 Nov 2017 16:34:24 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7ub1rb-1 for <tls@ietf.org>; Fri, 03 Nov 2017 16:34:24 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 44E0F211FC for <tls@ietf.org>; Fri, 3 Nov 2017 20:34:24 +0000 (GMT)
To: "tls@ietf.org" <tls@ietf.org>
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <FB95CAC8-C967-4724-90FB-B7E609DADF45@akamai.com> <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <f741b067-e7af-5231-4bb1-a0c2d151e6bf@nist.gov>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <0d7d639e-dd4d-eb05-9d63-85e69b330714@akamai.com>
Date: Fri, 3 Nov 2017 15:34:24 -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: <f741b067-e7af-5231-4bb1-a0c2d151e6bf@nist.gov>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-03_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711030248
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-03_08:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711030248
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rfbhPZyroGk8rkNhU8X5q7fHBKI>
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: Fri, 03 Nov 2017 20:34:29 -0000

Friday afternoon seems like a tolerable time to do something so
questionably productive as mailing to this thread...

On 10/25/2017 09:50 AM, David A. Cooper wrote:
> This question is based on your that belief that this protocol will
> "escape" onto the public Internet, that browsers and other clients
> used by individuals will feel forced to implement it, and that clients
> will then be forced to enable the extension in order to get through
> middleboxes that would filter traffic based on whether or not the
> extension is present in the ClientHello. I've already explained why I
> believe that scenario will never happen, and so no I do not agree that
> it is a "fundamental change."

Not picking on David in particular, it just happened to be the first
message I found going back through the thread that exhibited this
phenomenon.

Namely, I have seen a lot of reasoning along the lines of "this would
never happen on the public internet because there are so many other,
cheaper/more efficient/easier ways to do it".  I don't  find that line
of reasoning very persuasive.  This is not necessarily because I
disagree with the cheaper/more efficient/easier classification, but
rather because it seems out of scope for us as a technology
organization.  IMO, we ought to be considering all the potential
ramifications of a protocol change, in all the environments where that
protocol is or might be deployed, as a purely technological matter, so
that we can understand its potential impacts.  Just because something is
expensive or inefficient today does not mean that it is not a capability
of the technology we are developing, and cost and efficiency can change
over time.  In cryptanalysis, we do not discount attacks that require
large amounts of storage, because they are still valid algorithmic
attacks, and lo and behold, as storage gets cheaper, we find that these
sorts of attacks do get used.  Similarly for protocol design/analysis,
we should not discount a particular protocol interaction just because
there are at present other ways to do a similar thing, and those other
ways currently seem more attractive.

-Ben