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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 22 October 2017 22:26 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8389813BB88 for <tls@ietfa.amsl.com>; Sun, 22 Oct 2017 15:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 7CoOtn50DUTf for <tls@ietfa.amsl.com>; Sun, 22 Oct 2017 15:26:40 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12D513BB85 for <tls@ietf.org>; Sun, 22 Oct 2017 15:26:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61946BE4D; Sun, 22 Oct 2017 23:26:37 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQqexPAU3Inj; Sun, 22 Oct 2017 23:26:33 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1C7EDBE49; Sun, 22 Oct 2017 23:26:33 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1508711193; bh=TqHApQkYDM4CtSV2vqXTwrEUbBCHsjbVVZIREVwxagw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=u9YZ6SpgL6hGavt4sLeMX+y4diFKJxMbV9XUvbbFwl6vPoXwDjwBrf68UjAK2BTsT ibyVyF6xgAEk+GhlLhQJIT+dggG74S+oS/covgUK0+hRF2O9NT9FGZf7iIQ/+n50R5 Q7KoyGUftjxG6O+mFKDbbBo9bOQ4ifaRkWrAwzBY=
To: Steve Fenter <steven.fenter58@gmail.com>, "Salz, Rich" <rsalz@akamai.com>
Cc: "Ackermann, Michael" <MAckermann@bcbsm.com>, Darin Pettis <dpp.edco@gmail.com>, "tls@ietf.org" <tls@ietf.org>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <b20b2200-e00d-2579-b39e-664e37fabab3@cs.tcd.ie>
Date: Sun, 22 Oct 2017 23:26:32 +0100
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: <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nUxaQPSXAX9o3TEh2XuFUV51LI9f9VOcn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a7TtSW7iWl3DExhXoxerVmDciow>
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 22:26:42 -0000


On 22/10/17 21:48, Steve Fenter 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. I've also learned that getting a solution in place
> through the IETF is a multi-year process, and then vendor adoption
> time has to be added on top of that.  Enterprises don't want to be
> caught in a position where a vulnerability is forcing us to upgrade,
> and we are starting at ground zero on a multi-year process to restore
> TLS visibility. We have to get out in front of this problem so we're
> not caught unprepared.

Wait. What?

One of your arguments for needing snooping is that you
claim a lack of competence in debugging applications that
use TLS.

So to solve that, you propose we introduce a rarely used,
sporadically supported method of leaking keys to third
parties. IOW, you add what's called a vulnerability and
do so in a complex manner in code paths that'll hardly
ever be used (according to the proponents, they'll only
be used in the "proper" places, or at least, none of you
have so far ever acknowledged the falsity of that "proper"
places magical thinking).

Rarely used complex code for leaking keys... hmm, now
what is that likely to lead to? Oh yes, bugs.

But now you claim that a well tested protocol with fairly
mature implementations (TLS1.2) might have bugs that cause
you to need to add your additional complex key-leaking
vulnerability feature which'll magically have no bugs?

I think you can fairly claim a worst argument of the year
prize for that one;-)

S.

PS: Your claim about "guarantees" is just false afaics. I
saw no such thing on the list. Please desist from inventing
statements that were not made, or point me at where someone
said something that is even remotely possible to confuse
with such a guarantee. (Combining risible argument and false
claims really isn't wise.)


> 
> Sent from my iPad
> 
>> On Oct 20, 2017, at 11:57 AM, "Salz, Rich" <rsalz@akamai.com>;
>> wrote:
>> 
>> 
>> 
>> So it sounds like we are in agreement that continuing to use TLS
>> 1.2 is not a viable long term  alternative.
>> 
>> 
>> Long-term is a subjective term, and using it can lead to
>> misunderstandings.
>> 
>> Based on current and previous actions around SSL and TLS versions,
>> you can use TLS 1.2 for at least five, likely at least 10, years.
>> 
>> 
>> 
>> _______________________________________________ TLS mailing list 
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>