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

Ted Lemon <mellon@fugue.com> Sun, 22 October 2017 21:17 UTC

Return-Path: <mellon@fugue.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 B55E813B57B for <tls@ietfa.amsl.com>; Sun, 22 Oct 2017 14:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 kbMD4Ibl6qBe for <tls@ietfa.amsl.com>; Sun, 22 Oct 2017 14:17:36 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA9513B57D for <tls@ietf.org>; Sun, 22 Oct 2017 14:17:35 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id z19so23990462qtg.11 for <tls@ietf.org>; Sun, 22 Oct 2017 14:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nE+4XFYkYsbjRQg3Fkb1OJ7ijuUAMhY8lCosI7NFiYw=; b=Przt+h7oKJDyhvxXTqmEhux5Nxat72sdLgzHyD7bsJq1ZhzsEEHp1+7YLZ/OZ6HajK jhxDBCLmgfccyYvRhaFHQ+/gROQ1MR5cqqG97FcItpk6yRKQRxXmhfFshDxGf3S4iwia vBCuApkWh8Z6K95lJeHDNV0uDW3rYgZTcoidx1yptfs+p48ovgnFvBBjA3Udkm9yx/9K 4eozKp5IWKnW27e9WhZr/rHkvgRObrXDjB6zP7+qXbYK1DpQwn6DI09cVCmJoBA1LMgp DT0FPX5d2HDk5faImQUOnfsQZSU0fxZMGQAc6PVSUi4D1/GnNxw/Xxo2g6zAifi2xyAy 5bEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nE+4XFYkYsbjRQg3Fkb1OJ7ijuUAMhY8lCosI7NFiYw=; b=jLQkIiY3mc/x8XokQcHa7xWWFoJHHDVaR4MnrOHAG17GZonm1BYH7179nV+a068McF nzbQk02e+ACBthiSCeIqlg2P3c9mKF4c94bdemddAJUD5wUxJcH1TPC9Von7MyJfVRpg RnbuHyUPCPgJoWccn3yzgDSUaQwyK4xr3X+PbCJRa7QlbdUe6BsB486fQoqueNg9q/l1 3+xFFqzpqTnI6AtBmOVeoBiLeIgOHtMkGqiL8TrFKL3JWAPLx0OfpjBQvGrczl5NiuuN ugELHJTTT7965urD8jYAR/usaEiy2FQtthEpkWm5eN380MwiHiPXtYlKdWZic6Ec7USc CTPQ==
X-Gm-Message-State: AMCzsaVJZeXwGOxr7hPlkD0oCO0E0yI/zUtDf7GRbyxaKhNhSMAcGsST Vcdmk0QAT5HpWN6Yp1KFc//PCw==
X-Google-Smtp-Source: ABhQp+Q+Vxx1mgy6PvQvpvA3W0JDxWak7iVmGX8W6yayREp3w6GbuLxATdHOQ3bgx8MWfI7dS4C8Lg==
X-Received: by 10.200.48.37 with SMTP id f34mr17457340qte.228.1508707054576; Sun, 22 Oct 2017 14:17:34 -0700 (PDT)
Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q186sm3753427qkf.26.2017.10.22.14.17.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 14:17:33 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FECC7280-73BA-4ABD-8F5D-EAA6586CE600"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 22 Oct 2017 17:17:31 -0400
In-Reply-To: <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
To: Steve Fenter <steven.fenter58@gmail.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <e8417cc424fe4bf3b240416dfffd807a@venafi.com> <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com> <fd12a8a8c29e4c7f9e9192e1a1d972d6@venafi.com> <D2CAAA44-339E-4B41-BCE0-865C76B50E2F@akamai.com> <d76828f02fc34287a961eba21901247b@venafi.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <c1c0d010293c449481f8751c3b85d6ae@venafi.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <E84889BB-08B3-4A3A-AE3A-687874B16440@akamai.com> <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <CY4PR14MB1368CBA562220D9A3604F0FFD7430@CY4PR14MB1368.namprd14.prod.outlook.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <CY4PR14MB136835A3306DEEFCA89D3C2DD7430@CY4PR14MB1368.namprd14.prod.outlook.com> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jmA0C1DqkK7sFxZiufobEFCgUAo>
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: Sun, 22 Oct 2017 21:17:38 -0000

On Oct 22, 2017, at 4:48 PM, Steve Fenter <steven.fenter58@gmail.com> wrote:
> The main problem with not addressing the TLS visibility issue now is that no one knows when a vulnerability will be discovered in TLS 1.2 that forces enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the RSA key exchange are going to be fine for 5 to 10 years, but nobody knows that, particularly in today's security environment.

Implicit in this assertion is the claim that these organizations could switch quickly to TLS 1.3, but in fact we know that it's been very difficult for them to make the switch from 1.1 to 1.2, and in many cases they haven't done it.   So this isn't really at all persuasive.   But even if it were persuasive, it still wouldn't be a good argument.  TLS is a complicated protocol that does far more than is required for the use case we are talking about.   It would be better to use a simpler protocol with a smaller attack surface.

So why not get started on that now, instead of trying to weaken TLS 1.3?