Re: [TLS] Industry Concerns about TLS 1.3

BITS Security <BITSSecurity@fsroundtable.org> Mon, 03 October 2016 20:45 UTC

Return-Path: <BITSSecurity@fsroundtable.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 464BD129533 for <tls@ietfa.amsl.com>; Mon, 3 Oct 2016 13:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fsroundtable.onmicrosoft.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 ilQMURdvxCsa for <tls@ietfa.amsl.com>; Mon, 3 Oct 2016 13:45:40 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0089.outbound.protection.outlook.com [104.47.36.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F147129508 for <tls@ietf.org>; Mon, 3 Oct 2016 13:45:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsroundtable.onmicrosoft.com; s=selector1-fsroundtable-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vp9UXzfalXL5l1R2eFzz4ylxpJOBQb1mQNoYfvY2VoU=; b=fUYVe+nLTAE9VE2cONOwU5eFnDa/Bn9w5mQ7kltBoR9Nny7xvaLilF9GL99eIiMfrNWXd33HRyslkFn8J5OiNXKrQMWf7Fc9QxkLT2UNOIyFw8oxtBz3LX2dwHbOwV6yudHl0evulbaWn2fSvERKAfwCvn2zFb8uG9Zcno6gZIk=
Received: from DM5PR11MB1419.namprd11.prod.outlook.com (10.168.104.21) by DM5PR11MB1420.namprd11.prod.outlook.com (10.168.104.22) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.649.16; Mon, 3 Oct 2016 20:45:38 +0000
Received: from DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) by DM5PR11MB1419.namprd11.prod.outlook.com ([10.168.104.21]) with mapi id 15.01.0619.020; Mon, 3 Oct 2016 20:45:38 +0000
From: BITS Security <BITSSecurity@fsroundtable.org>
To: Seth David Schoen <schoen@eff.org>
Thread-Topic: [TLS] Industry Concerns about TLS 1.3
Thread-Index: AdIU8WqWM9WBapZoQzyfqxiOaK25faCNrW8AgAACpQCACY+AcA==
Date: Mon, 3 Oct 2016 20:45:38 +0000
Message-ID: <DM5PR11MB1419BA2AD17900161C206CC9F4C20@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CADi0yUPZzLrPize4eKpASdM=2nm1h1T2UXs7_sdk2eDv=ku_2w@mail.gmail.com> <DM5PR11MB14192A617ED199BB83E920C4F4CC0@DM5PR11MB1419.namprd11.prod.outlook.com> <20160927183022.GM25826@demorgan>
In-Reply-To: <20160927183022.GM25826@demorgan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=BITSSecurity@fsroundtable.org;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [165.117.248.226]
x-ms-office365-filtering-correlation-id: 724c8bb0-4f2f-4cf8-9d61-08d3ebce3b9d
x-microsoft-exchange-diagnostics: 1; DM5PR11MB1420; 7:Dcdk0LjCGTuxK69mysrQAbAhFgeapmH5LBC5O5T1sywT1+zhhtJgNd+g7Mw14tiUdMoT+3f1RfYdHt89HjbEIZBZlGK6rxWRqK8YxanOVsgjseW8zCNeFVDv/zFB/p4kx2ysnlMdCgGq60wO1dpC8+awNQam6x6SYxT0HO5ft68O3zqiwEnlIVLtPwJMXKLtR0h5L9uFRUJtpW+llkyfg+6GH2sD6yj4fMS/9TSWoQ0PzwZcCqsa2cMRN1qi+wJFPLHiDZDCs2PB002RHs7VkC8sx9UE3UsuRY6cS+CMvgXAnpXfhNrnoaxZltPcOVxVu+IOCTLQO6E2Fi7r+Nx0hA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR11MB1420;
x-microsoft-antispam-prvs: <DM5PR11MB14207D62ADCA10947FE21831BDC20@DM5PR11MB1420.namprd11.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(264723453828037)(192374486261705)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:DM5PR11MB1420; BCL:0; PCL:0; RULEID:; SRVR:DM5PR11MB1420;
x-forefront-prvs: 008421A8FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(13464003)(199003)(189002)(76576001)(5002640100001)(80792005)(87936001)(122556002)(19580405001)(110136003)(74316002)(7696004)(97736004)(7736002)(2906002)(19580395003)(15975445007)(305945005)(189998001)(3280700002)(86362001)(93886004)(101416001)(2950100002)(3660700001)(7846002)(77096005)(4326007)(9686002)(6916009)(106356001)(105586002)(11100500001)(6116002)(92566002)(76176999)(10400500002)(66066001)(8676002)(54356999)(68736007)(33656002)(50986999)(99286002)(102836003)(2900100001)(81156014)(5660300001)(81166006)(3846002)(586003)(8936002)(19400905002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1420; H:DM5PR11MB1419.namprd11.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fsroundtable.org does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: fsroundtable.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2016 20:45:38.2364 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 841de5a0-73e8-4cbc-8142-f80b225ef22d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1420
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/m36Re6z9ReQpfUSSgHNFp0CpcoQ>
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: Mon, 03 Oct 2016 20:45:44 -0000

> > The various suggestions for creating fixed/static Diffie Hellman keys raise interesting possibilities.  We would like to understand these ideas better at a technical level and are initiating research into this potential solution.  We need to understand the potential ramifications and other implementation details.  This solution would have to be implemented in servers, firewalls, load balancers, Internet proxies, and mainframes.  If vendors broadly refuse to support then it is not much a solution but at this point looks like it is worth exploring.  

> Bear in mind that, if you do that, anyone who gets a copy of that secret will be able to retrospectively decrypt all of your organization's TLS traffic.  However, that's presumably true of any solution that satisfies the requirement that you describe: there will always be _some_ secret that the organization possesses that, if obtained by an adversary, would let the adversary retrospectively decrypt traffic.

We can put private keys in an HSM and implement other processes to protect them.  This is what some are doing with RSA today.  If you look at the Verizon breach report and other similar resources, breaches from stolen network packets and/or stolen private keys is not a discernible trend (though I will cede past results don't predict future performance). 

> This configuration might be a bit dangerous because it means that "servers, firewalls, load balancers, Internet proxies, and mainframes"
would all possess the information needed to decrypt _each other's_ traffic, so someone inside or outside the organization who can steal that information can then read all of the traffic, even traffic that was originated by devices they don't know about or have a relationship to.
> So organizational unit X can read the traffic of organizational unit Y, even if X wasn't meant to be in a supervisory or audit relationship over Y, because the ability to emit decryptable traffic of this kind also implies the ability to decrypt others' sessions.

We've heard this a different way, for example not every layer of the data center would have the same key or that key is always available. I have to admit to some ignorance here which is why we want to explore this potential option.  Even if it works (which it might not as you say) there still is the question of if vendors would being willing to support.  

> It also provides a way that other parties outside of the organization can, even through passive eavesdropping, recognize the organization's traffic as associated with that organization -- kind of like a global cookie inside the TLS handshake.  People could use that to target surveillance or advertising even if they didn't know or recognize the organization's IP address ranges.

Something else important to check on that could undermine this solution.  Appreciate it.  

- Andrew 




-----Original Message-----
From: Seth David Schoen [mailto:schoen@eff.org] 
Sent: Tuesday, September 27, 2016 2:30 PM
To: BITS Security <BITSSecurity@fsroundtable.org>;
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

BITS Security writes:

> The various suggestions for creating fixed/static Diffie Hellman keys raise interesting possibilities.  We would like to understand these ideas better at a technical level and are initiating research into this potential solution.  We need to understand the potential ramifications and other implementation details.  This solution would have to be implemented in servers, firewalls, load balancers, Internet proxies, and mainframes.  If vendors broadly refuse to support then it is not much a solution but at this point looks like it is worth exploring.  

Bear in mind that, if you do that, anyone who gets a copy of that secret will be able to retrospectively decrypt all of your organization's TLS traffic.  However, that's presumably true of any solution that satisfies the requirement that you describe: there will always be _some_ secret that the organization possesses that, if obtained by an adversary, would let the adversary retrospectively decrypt traffic.

This configuration might be a bit dangerous because it means that "servers, firewalls, load balancers, Internet proxies, and mainframes"
would all possess the information needed to decrypt _each other's_ traffic, so someone inside or outside the organization who can steal that information can then read all of the traffic, even traffic that was originated by devices they don't know about or have a relationship to.
So organizational unit X can read the traffic of organizational unit Y, even if X wasn't meant to be in a supervisory or audit relationship over Y, because the ability to emit decryptable traffic of this kind also implies the ability to decrypt others' sessions.

It also provides a way that other parties outside of the organization can, even through passive eavesdropping, recognize the organization's traffic as associated with that organization -- kind of like a global cookie inside the TLS handshake.  People could use that to target surveillance or advertising even if they didn't know or recognize the organization's IP address ranges.

--
Seth Schoen  <schoen@eff.org>;
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107