Re: [TLS] Industry Concerns about TLS 1.3

Seth David Schoen <schoen@eff.org> Tue, 27 September 2016 18:37 UTC

Return-Path: <schoen@eff.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 2127D12B2C0 for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 11:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.319
X-Spam-Level:
X-Spam-Status: No, score=-9.319 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_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 vuYtxUguRnqn for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 11:37:53 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BBF12B31A for <tls@ietf.org>; Tue, 27 Sep 2016 11:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=oSb+HxoqFTMxzKslnN7AzVaQVhBP/U61kLvYiQSIILs=; b=gVmaIoI1EW2QjJS8KQCJeVJKTDETsSMD2SK3UK/e5ajd9jo+K0jcT9leVmis8sViYf5goSs0aQGy0N3SJFKpCpDGt7+iVzAzaQ6iGqwsd3/RIQ4UrQNwT3SsfXy9n1jZ6IMtQmYSP4Y02mufTVgcc9QHQa731N+3L8tDy28OwiU=;
Received: from localhost ([127.0.0.1]:42125 helo=demorgan) by mail2.eff.org with esmtp (Exim 4.80) (envelope-from <schoen@eff.org>) id 1box95-0002rC-2B; Tue, 27 Sep 2016 11:30:23 -0700
Date: Tue, 27 Sep 2016 11:30:22 -0700
From: Seth David Schoen <schoen@eff.org>
To: BITS Security <BITSSecurity@fsroundtable.org>
Message-ID: <20160927183022.GM25826@demorgan>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CADi0yUPZzLrPize4eKpASdM=2nm1h1T2UXs7_sdk2eDv=ku_2w@mail.gmail.com> <DM5PR11MB14192A617ED199BB83E920C4F4CC0@DM5PR11MB1419.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM5PR11MB14192A617ED199BB83E920C4F4CC0@DM5PR11MB1419.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7ohh9Bb2O-ii58Dp9kGEm-sivac>
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: Tue, 27 Sep 2016 18:37:55 -0000

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