Re: [TLS] Industry Concerns about TLS 1.3

Hubert Kario <hkario@redhat.com> Thu, 29 September 2016 11:47 UTC

Return-Path: <hkario@redhat.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 ABE3912B094 for <tls@ietfa.amsl.com>; Thu, 29 Sep 2016 04:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.218
X-Spam-Level:
X-Spam-Status: No, score=-9.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 gspz931mDJdQ for <tls@ietfa.amsl.com>; Thu, 29 Sep 2016 04:47:53 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D9012B0EB for <tls@ietf.org>; Thu, 29 Sep 2016 04:38:25 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2751AC05678D; Thu, 29 Sep 2016 11:38:25 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (vpn1-4-150.ams2.redhat.com [10.36.4.150]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8TBcM9h022289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Sep 2016 07:38:24 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 29 Sep 2016 13:38:16 +0200
Message-ID: <86778027.38QMZb0QrK@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.1 (Linux/4.7.4-200.fc24.x86_64; KDE/5.26.0; x86_64; ; )
In-Reply-To: <DM5PR11MB1419982941ECB14040873E6AF4CC0@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <20160927182409.GA26653@LK-Perkele-V2.elisa-laajakaista.fi> <DM5PR11MB1419982941ECB14040873E6AF4CC0@DM5PR11MB1419.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2099933.ZdYkNjfDZS"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 29 Sep 2016 11:38:25 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8N7vRQ0BkPXrq7tooKG_i_lq_WI>
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 11:47:55 -0000

On Tuesday, 27 September 2016 18:34:30 CEST BITS Security wrote:
> Ilari - I understand yours (and others) view on this but there is no
> technical reason why this couldn't be part of the standard.  A potential
> solution, like many cipher suite *choices* in past versions of TLS, would
> be optional and up to both clients and servers to configure what they are
> willing to support (or not support).  You appear to be assuming everyone is
> running off the same set of requirements (one-size-fits-all) and we are
> here to tell you that isn't necessarily true.

if you're willing to forge One Ring to rule them all, using static server key 
shares in TLSv1.3 doesn't change anything in your ability to compromise 
security of all the connections in your network. It also doesn't require any 
changes to TLSv1.3 to work. Yes, it will require changes to MitM boxes and 
decryption software, but that's the case for any new protocol version, isn't 
it?

> 
> - Andrew
> 
> 
> 
> 
> -----Original Message-----
> From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]
> Sent: Tuesday, September 27, 2016 2:24 PM
> To: BITS Security <BITSSecurity@fsroundtable.org>
> Cc: Eric Rescorla <ekr@rtfm.com>; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
> 
> On Tue, Sep 27, 2016 at 06:07:28PM +0000, BITS Security wrote:
> > Hi Eric--Thank you for the prompt.
> > 
> > Our requirements are for the same capabilities we have today with TLS
> > 1.2, namely to be able to take a trace anywhere in our enterprise and
> > decrypt it out of band (assuming that we own the TLS server).  This
> > includes traces taken from physical taps, traces from span or mirror
> > ports, traces from the virtual environment, and/or traces from agents
> > on workstations.  We need to be able to apply a key to sniffer
> > devices, security and fraud monitoring tools, APM devices, and/or TLS
> > decryption appliances.
> 
> No changes to standards are going to happen to make that any easier.
> Don't waste your time.
> 
> 
> -Ilari
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic