Re: [TLS] Industry Concerns about TLS 1.3

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 26 September 2016 23:09 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 48B6012B260 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2016 16:09:44 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 Ig4m6I1knQCa for <tls@ietfa.amsl.com>; Mon, 26 Sep 2016 16:09:42 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C20712B05C for <tls@ietf.org>; Mon, 26 Sep 2016 16:09:42 -0700 (PDT)
Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 10C32282FA6 for <tls@ietf.org>; Mon, 26 Sep 2016 23:09:41 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <DM5PR11MB1419320109EC18605B1D2072F4CD0@DM5PR11MB1419.namprd11.prod.outlook.com>
Date: Mon, 26 Sep 2016 19:09:48 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD40CD6E-568F-40A3-838F-C4AC9C9AF9C8@dukhovni.org>
References: <DM5PR11MB14191AABED7E43F904133787F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <r470Ps-10116i-4C64C69C85D443BF91A20D2FDB8F48E9@Williams-MacBook-Pro.local> <DM5PR11MB1419320109EC18605B1D2072F4CD0@DM5PR11MB1419.namprd11.prod.outlook.com>
To: "tls@ietf.org" <tls@ietf.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UzVCtgsGZ20r1VGW611prxj-ua0>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "tls@ietf.org" <tls@ietf.org>
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: Mon, 26 Sep 2016 23:09:44 -0000

> On Sep 26, 2016, at 3:23 PM, BITS Security <BITSSecurity@fsroundtable.org>; wrote:
> 
> That said, at least one of the sites you mentioned was known to have an APT inside their perimeter (Operation Aurora) for about a month and part of the tactics within that attack which was publicly reported was the use of "SSL" to mask C&C communications. That's the type of threat we are concerned about inside of the enterprise network and we need visibility (and flexibility appropriate to our network design and risk tolerance) to solve for these issues in way that protects people like the ones you mentioned.  

I very much doubt that the APT C&C traffic went out of its way to use
RSA key exchange to make the traffic enterprise-friendly, or even if
it happened to use RSA key exchange that the private keys were available
to the victim site...

All that RSA key exchange gives you is the ability to use long-term
keys of servers you control to decrypt past traffic through that server
if the private keys are still (or for better or worse become) available.

There are other ways to accomplish this.  For example, the server might
use session ticket keys that are stored centrally encrypted under a
suitable escrow key.  If clients always enable session tickets, then
every handshake will result in the server returning a session ticket,
in which case the session can be later decrypted if the session ticket
keys are available.

There's no need to change to the TLS protocol to make such things
possible, it is sufficient to purchase server devices that in one
way or another record session master secrets for later recovery.

There will surely be vendors who'll be more than happy to be paid
to fulfill any business needs in this space.

Having worked in IT security in the financial services industry for
more than a couple of decades now, I am rather surprised and somewhat
appalled by this thread.  I don't believe that the concerns raised
should in any way influence protocol design.  Products that offer less
forward-secrecy than the protocol would otherwise deliver will be
available to those who control either or both end-points and need
to be able to be able to produce after-the-fact plaintext.

The good news about doing key escrow deliberately, rather than
as an unintended side-effect of RSA key exchange, is that it
can be both more reliable and more secure, since the escrow
private keys need not be the same as the server long-term
authentication keys, and are therefor less vulnerable.

RSA key exchange has a long history of problems, and it is time to
move on.  We should not be overly attached to one particular way of
doing key escrow.

-- 
-- 
	Viktor.