Re: [TLS] Industry Concerns about TLS 1.3

Bill Frantz <frantz@pwpconsult.com> Thu, 29 September 2016 05:28 UTC

Return-Path: <frantz@pwpconsult.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 B9A3E12B057 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 22:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
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 4tRAr1rXCsGP for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 22:28:16 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47F912B051 for <tls@ietf.org>; Wed, 28 Sep 2016 22:28:15 -0700 (PDT)
Received: from [47.143.125.162] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1bpTt6-0003Ra-Cx; Thu, 29 Sep 2016 01:28:04 -0400
Date: Wed, 28 Sep 2016 22:27:54 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: Melinda Shore <melinda.shore@nomountain.net>
X-Priority: 3
In-Reply-To: <8cb4bacf-e9a3-9e85-5a4f-e7208ff1c60f@nomountain.net>
Message-ID: <r470Ps-10116i-7117094C6B814474BAD619DF6773E0AD@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4 (470)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79e56446c226e0a5f12499822eb8bc66c8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 47.143.125.162
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P_NCerrybYmzEDFtgr9qGKmOSOA>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 29 Sep 2016 05:28:18 -0000

On 9/28/16 at 4:27 PM, melinda.shore@nomountain.net (Melinda 
Shore) wrote:

>That said, IETF participation is dominated by large equipment and
>software vendors and the problem space, at least until recently
>(there's been a crop of data center-related problems coming up in
>OPS and routing), has tended to cover service provider-related
>questions.  We have poor participation and representation from
>enterprise networks.  So now we've got someone showing up from
>the enterprise space and saying "I have this problem related to
>protocol changes."  And yeah, he's very, very late in this
>process, although it's worth pointing out that it's in the best
>tradition of the IETF to deal with technical problems that crop
>up with documents at any point in their development.

While I fully support trying to design protocols so applications 
and networks can be managed by enterprises (and indeed home 
users), I do not want to see IETF security protocols become more 
complex as a result. That will only make them easy targets for 
attackers. The Clipper chip shows what happens when even experts 
design key recovery systems.

I hope one outcome of this thread is that industry groups which 
use IETF protocols will realize that the best way to have their 
needs recognized is to be active in the relevant groups from the 
beginning and for the long term. I know of no other way to make 
the proper tradeoffs except to have all the issues in front of 
the working group from the beginning of their process. That 
involvement will strengthen the IETF while making sure 
enterprise issues are addressed.

Even as late comers to the process, BITS Security has gotten a 
number of suggestions for ways forward which do not change the 
emerging TLS 1.3 standard. Given that it will be several years 
before regulators require TLS 1.3, vendors will be able step 
forward to fill this need with endpoint logging as well as other 
techniques embedded in "install and run" products. Given the 
list of companies that Tony linked, these products should enjoy 
a profitable market.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032